idnits 2.17.1 draft-calhoun-diameter-mobileip-03.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 33 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 34 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1264 has weird spacing: '...Timeout will ...' == Line 1503 has weird spacing: '... copied and ...' == Line 1504 has weird spacing: '...s, and deriv...' == Line 1506 has weird spacing: '...blished and d...' == Line 1507 has weird spacing: '...hat the above...' == (6 more instances...) == 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 1438, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1441, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-10 -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-04 -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Normative reference to a draft: ref. '3' ** Obsolete normative reference: RFC 2002 (ref. '4') (Obsoleted by RFC 3220) == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-challenge-04 ** 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 (-06) exists of draft-ietf-mobileip-mn-nai-05 == Outdated reference: A later version (-04) exists of draft-calhoun-diameter-proxy-03 -- 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-00 -- Possible downref: Normative reference to a draft: ref. '12' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '13') -- Duplicate reference: RFC2002, mentioned in '14', was also mentioned in '4'. ** Obsolete normative reference: RFC 2002 (ref. '14') (Obsoleted by RFC 3220) -- No information found for draft-ietf-mobileip-aaa-keys - is the name correct? -- Possible downref: Normative reference to a draft: ref. '15' Summary: 12 errors (**), 0 flaws (~~), 18 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Pat R. Calhoun 2 Category: Standards Track Sun Laboratories, Inc. 3 Title: draft-calhoun-diameter-mobileip-03.txt Charles E. Perkins 4 Date: October 1999 Nokia Research Center 6 DIAMETER Mobile IP Extensions 8 Status of this Memo 10 This document is an individual contribution for consideration by the 11 AAA Working Group of the Internet Engineering Task Force. Comments 12 should be submitted to the diameter@ipass.com mailing list. 14 Distribution of this memo is unlimited. 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at: 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at: 33 http://www.ietf.org/shadow.html. 35 Abstract 37 DIAMETER is an Authentication, Authorization and Accounting (AAA) 38 Policy Protocol that is used between two entities for various 39 services. This document defines an extension that allow a DIAMETER 40 Client to request authentication and receive autorization information 41 for a Mobile IP Mobile Node. 43 Table of Contents 45 1.0 Introduction 46 1.1 Copyright Statement 47 1.2 Requirements language 48 1.3 Changes in version 02 49 1.4 Changes in version 03 50 2.0 Command Codes 51 2.1 AA-Mobile-Node-Request (AMR) 52 2.2 AA-Mobile-Node-Answer (AMA) 53 2.3 Home-Agent-MIP-Request (HAR) 54 2.4 Home-Agent-MIP-Answer (HAA) 55 2.5 Mobile-Node-Terminate-Ind (MTI) 56 3.0 DIAMETER AVPs 57 3.1 MIP-Registration-Request 58 3.2 MIP-Registration-Reply 59 3.3 MN-FA-Challenge-Length 60 3.4 MN-FA-Response 61 3.5 MN-to-FA-Key 62 3.6 FA-to-MN-Key 63 3.7 FA-to-HA-Key 64 3.8 HA-to-FA-Key 65 3.9 MN-to-HA-Key 66 3.10 HA-to-MN-Key 67 3.11 Mobile-Node-Address 68 3.12 Home-Agent-Address 69 3.13 Previous-FA-NAI 70 3.14 Foreign-Home-Agent-Available 71 3.15 MN-AAA-SPI 72 4.0 Protocol Definition 73 4.1 Feature Advertisement/Discovery 74 4.2 Inter-Domain Mobile IP 75 4.3 Allocation of Home Agent in Foreign Network 76 4.4 DIAMETER Session Termination 77 5.0 Acknowledgements 78 6.0 IANA Considerations 79 7.0 References 80 8.0 Authors' Addresses 81 9.0 Full Copyright Statement 83 1.0 Introduction 85 The Mobile IP [4] protocol defines a method that allows a Mobile Node 86 to change its point of attachment to the Internet without service 87 disruption. The protocol requires that all Mobility Agents share a 88 pre-existing security association, which leads to scaling and 89 configuration problems. Mobile IP also does not mention how Mobility 90 Agents account for services rendered, which does not make it an 91 attractive protocol for use by service providers. 93 This document specifies extensions to DIAMETER that allow cross- 94 domain authentication and authorization, assignment of Mobile Node 95 Home Addresses, assignment of Home Agent, as well as Key Distribution 96 to allow the Mobile IP network to scale in a large network of service 97 providers. 99 The dynamic assignment of Mobile Node and Home Agent addresses are 100 useful for Service Providers wishing to provide Mobile IP services 101 for mobile nodes. 103 The DIAMETER Accounting extension [12] will be used by the Foreign 104 and Home agents to transfer usage information to the DIAMETER 105 servers. 107 Small modifications to the Mobile IP protocol [4], which already 108 exists in the TEP protocol [8], to allow a Mobile Node to identify 109 itself using an NAI [6] in addition to an IP address. The use of the 110 Network Access Identifier (NAI) [6] is consistent with the current 111 roaming model which makes use of DIAMETER proxying [7]. 113 The Extension number for this draft is four (4). This value is used 114 in the Extension-Id Attribute value Pair (AVP) as defined in [1]. 116 1.1 Copyright Statement 118 Copyright (C) The Internet Society 1999. All Rights Reserved. 120 1.2 Requirements language 122 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 123 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 124 described in [11]. 126 1.3 Changes in version 02 128 The following are the changes done to version 03 of the draft: 130 - Cleaned up the AVP Header flags 132 - The Command Code sections now show an optional Proxy-State AVP 133 as part of the message format. 135 - The previous version required that the MIP-Registration-Reply be 136 present in the AMA, but the AVP could not be present if the AAAH 137 could not service the request. The AVP is now only mandatory if 138 the AMA is successful. 140 - Cleaned up the description of the various key and SPI AVPs. 142 - Added text in section 4.2 that describes how the AAAH can cache 143 the keys directed for the AAAF so they can be included in the 144 message when the response is received by the HA. This was the 145 point that cause interoperability at the bake-off due to the fact 146 that it was quite unclear. 148 - Section 4.2 now correctly states that the Home-Address AVP MUST 149 be present and MAY have a value of 0.0.0.0. 151 - Section 4.2 now also states that the Mobile-IP FA-HA and the 152 MN-HA authentication extensions must be used. 154 - Added a reference to ESP 156 - Added IANA Considerations 158 1.4 Changes in version 03 160 The version 3 of this document contains many changes as a result of 161 the DIAMETER Document Reading Party, and other ommisions found after 162 the party. Many editorial changes have been done in addition to the 163 following items: 165 - DIAMETER_ERROR_UNKNOWN_DOMAIN has been removed from section 2.2 166 since this is already provided by the base protocol [1]. 168 - Section 3.4 contains new text on the purpose of the MN-FA- 169 Response, and how it is computed. 171 - The MN-FA, MN-HA and FA-HA SPI AVPs are no longer supported. The 172 various key extensions contain the SPI embedded within the AVP. 173 This reduces the number of AVPs, and is consistent with the key 174 encoding mechanism described in [15]. 176 - Key lifetime AVP in section 4.2 was changed to Session-Timeout 177 AVP. 179 - The Mobile-Node-Terminate-Ind messages were added (section 2.5). 181 - Oh, and one of the author's affiliation changed. 183 2.0 Command Codes 185 This section will define the Commands [1] for DIAMETER 186 implementations supporting the Mobile IP extension. 188 Command Name Command Code 189 --------------------------------------- 190 AA-Mobile-Node-Request 306 191 AA-Mobile-Node-Answer 307 192 Home-Agent-MIP-Request 308 193 Home-Agent-MIP-Answer 309 194 Mobile-Node-Terminate-Ind ??? 196 2.1 AA-Mobile-Node-Request (AMR) 198 Description 200 The AA-Mobile-Node-Request is sent by a Foreign Agent acting as a 201 DIAMETER client to a server to request authentication and 202 authorization of a Mobile Node. 204 The AA-Mobile-Node-Request message MUST include the MIP- 205 Registration-Request, User-Name, MN-FA-Challenge-Length, MN-FA- 206 Response AVP as well as the Session-ID AVPs. 208 The Mobile-Node-Address AVP contains the the Home Address found in 209 the Mobile Node's Registration Request. The Home-Agent-Address AVP 210 contains the Home Address found in the Registration Request. If 211 the Home Address is zero, it indicates that the Mobile Node is 212 requesting that an address be allocated to it. 214 The User-Name AVP contains the NAI found in the Mobile IP 215 Registration Request's Mobile-Node-NAI Extension. 217 If the Previous-FA-NAI AVP is found in the request, the DIAMETER 218 Client is requesting that the Server return the Session Key that 219 was assigned to the previous Foreign Agent for use with the Mobile 220 Node. The Session Key is identified through the use of the 221 Mobile-Node-Address AVP. 223 Message Format 224 ::= 225 226 227 228 229 230 231 232 233 234 [] 235 [] 236 237 238 { || 239 } 241 The length of the DIAMETER Command AVP must be 12 when the Command 242 Code is set to 306 (AA-Mobile-Node-Request). 244 2.2 AA-Mobile-Node-Answer (AMA) 246 Description 248 The AA-Mobile-Node-Answer is sent by the DIAMETER Server to the 249 client in response to the AA-Mobile-Node-Request message. The 250 message MUST include the Session-Id, Result-Code as well as the 251 various key AVPs (see section 3.0) and MAY include the Home- 252 Agent-Address and Mobile-Node-Address AVPs. A successful response 253 MUST include the MIP-Registration-Reply AVP. 255 The Home-Agent-Address AVP contains the Home Agent assigned to the 256 Mobile Node. If the AVP contains a zero address, it is a request 257 to allocate a Home Agent locally. 259 The Mobile-Node-Address AVP contains the IP Address assigned to 260 the Mobile Node. If this AVP contains a zero address, it is a 261 request to allocate a Home Address for the Mobile Node. 263 The following error codes are defined for this message for use in 264 the Error-Code AVP [1]: 266 DIAMETER_ERROR_USER_UNKNOWN 1 267 This error code is used to indicate to the initiator that 268 the username request is not valid. 270 DIAMETER_ERROR_BAD_PASSWORD 2 271 This error code indicates that the password provided is 272 invalid. 274 DIAMETER_ERROR_CANNOT_AUTHORIZE 3 275 This error code is used to indicate that the user cannot be 276 authorized due to the fact that the user has expended local 277 resources. This could be a result that the server believes 278 that the user has already spent the number of credits in 279 his/her account, etc. 281 Message Format 283 ::= 284 285 286 287 [] 288 [] 289 290 291 292 293 294 [] 295 296 297 { || 298 } 300 The length of the DIAMETER Command AVP must be 12 when the Command 301 Code is set to 307 (AA-Mobile-Node-Answer). 303 2.3 Home-Agent-MIP-Request (HAR) 305 Description 307 The Home-Agent-MIP-Request is sent by the home DIAMETER server to 308 the Home Agent overseeing the Mobile Node to process the Mobile IP 309 Registration Request. 311 The Home-Agent-MIP-Request message MUST include the MIP- 312 Registration-Request, User-Name, Session-ID as well as the key 313 AVPs (see section 3.0) to be used by the Mobile Node and the Home 314 Agent. 316 If the Mobile-Node-Address AVP is set to a zero Address, it is a 317 request to the Home Agent to allocate a Home Address to the Mobile 318 Node. 320 Message Format 322 ::= 323 324 325 326 327 328 329 330 331 332 333 334 [] 335 336 337 { || 338 } 340 The length of the DIAMETER Command AVP must be 12 when the Command 341 Code is set to 308 (Home-Agent-MIP-Request). 343 2.4 Home-Agent-MIP-Answer (HAA) 345 Description 347 The Home-Agent-MIP-Answer is sent by the Home Agent to the home 348 DIAMETER Server in response to the Home-Agent-MIP-Request. The 349 message MUST include the Session-Id, Result-Code, MIP- 350 Registration-Reply and the Mobile-Node-Address. 352 The following error codes are defined for this message for use in 353 the Error-Code AVP [1]: 355 DIAMETER_ERROR_BAD_KEY 1 356 This error code is used by the Home Agent to indicate to the 357 local DIAMETER Server that the key generated is invalid. 359 DIAMETER_ERROR_BAD_HOME_ADDRESS 2 360 This error code is used by the Home Agent to indicate that 361 the Home Address chosen by the Mobile Node or assigned by 362 the local DIAMETER server is unavailable. 364 DIAMETER_ERROR_TOO_BUSY 3 365 This error code is used by the Home Agent to inform the 366 DIAMETER Server that it cannot handle an extra Mobile Node. 367 Upon receiving this error the DIAMETER Server can try to use 368 an alternate Home Agent if one is available. 370 DIAMETER_ERROR_MIP_REPLY_FAILURE 4 371 This error code is used by the Home Agent to inform the 372 DIAMETER Server that the Registration Request failed. 374 Message Format 376 ::= 377 378 379 380 [] 381 382 383 384 [] 385 386 387 { || 388 } 390 The length of the DIAMETER Command AVP must be 12 when the Command 391 Code is set to 309 (Home-Agent-MIP-Answer). 393 2.5 Mobile-Node-Terminate-Ind (MTI) 395 Description 397 The Mobile-Node-Terminate-Ind is sent by a Foreign Agent or Home 398 Agent as a DIAMETER client to a server to inform the server that 399 an active session has been terminated. The MTS message can be sent 400 by a DIAMETER Server to a client in order to request that an 401 active session be terminated. 403 The Mobile-Node-Terminate-Ind message MUST include the Session-Id, 404 User-Name, Home-Agent-Address and Mobile-Node-Address AVPs. 406 Message Format 407 Mobile-Node-Terminate-Ind ::= 408 409 410 411 412 413 [] 414 415 416 { || 417 } 419 The length of the DIAMETER Command AVP must be 12 when the Command 420 Code is set to ??? (Mobile-Node-Terminate-Ind). 422 3.0 DIAMETER AVPs 424 This section will define the mandatory AVPs which MUST be supported 425 by all DIAMETER implementations supporting this extension. The 426 following AVPs are defined in this document: 428 Attribute Name Attribute Code Definition in Section 429 ------------------------------------------------------------ 430 MIP-Registration-Request 320 3.1 431 MIP-Registration-Reply 321 3.2 432 MN-FA-Challenge-Length 322 3.3 433 MN-FA-Response 323 3.4 434 MN-to-FA-Key 325 3.5 435 FA-to-MN-Key 326 3.6 436 FA-to-HA-Key 328 3.7 437 HA-to-FA-Key 329 3.8 438 MN-to-HA-Key 331 3.9 439 HA-to-MN-Key 332 3.10 440 Mobile-Node-Address 333 3.11 441 Home-Agent-Address 334 3.12 442 Previous-FA-NAI 335 3.13 443 MN-AAA-SPI 336 3.14 445 3.1 MIP-Registration-Request 447 Description 449 This AVP is used to carry the Mobile IP Registration Request [4] 450 sent by the Mobile Node to the Foreign Agent within a DIAMETER 451 message. 453 AVP Format 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 AVP Header (AVP Code = 320) 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Data ... 461 +-+-+-+-+-+-+-+-+ 463 AVP Flags 464 The 'M' bit MUST be set. The 'P' bit MAY be set if end to end 465 message integrity is required. The 'H' or 'E' may be set if 466 the AVP is to be encrypted. The 'V', 'H' and 'T' bits MUST NOT 467 be set. 469 Data 470 The data field contains the Mobile IP Registration Request. 472 3.2 MIP-Registration-Reply 474 Description 476 This AVP is used to carry the Mobile IP Registration Reply [4] 477 sent by the Home Agent to the Foreign Agent within a DIAMETER 478 message. 480 AVP Format 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 AVP Header (AVP Code = 321) 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Data ... 488 +-+-+-+-+-+-+-+-+ 490 AVP Flags 491 The 'M' bit MUST be set. The 'P' bit MAY be set if end to end 492 message integrity is required. The 'H' or 'E' may be set if 493 the AVP is to be encrypted. The 'V', 'H' and 'T' bits MUST NOT 494 be set. 496 Data 497 The data field contains the Mobile IP Registration Reply. 499 3.3 MN-FA-Challenge-Length 501 Description 503 The MN-FA-Challenge-Length AVP contains the number of octets in 504 the MIP-Registration-Request AVP that are to be used by the 505 DIAMETER server to compute the Response, as described in section 506 3.4. 508 AVP Format 510 0 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 AVP Header (AVP Code = 322) 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Integer32 | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 AVP Flags 519 The 'M' bit MUST be set. The 'P' bit MAY be set if end to end 520 message integrity is required. The 'H' or 'E' may be set if 521 the AVP is to be encrypted. The 'V', 'H' and 'T' bits MUST NOT 522 be set. 524 Integer32 525 The Integer32 field contains the number of octets in the MIP- 526 Registration-Request AVP that are used to generate the 527 Challenge Response, and authenticate the Mobile Node. 529 3.4 MN-FA-Response 531 Description 533 This AVP contains the Response generated by the Mobile Node as 534 defined in the Mobile IP MN-AAA authentication extension [5]. The 535 AVP contains the value of the authenticator field in the 536 authentication extension. The authenticator is the value computed 537 by the mobile node using the Registration Request and the security 538 association it shares with its Home DIAMETER Server. 540 The Mobile Node's Home DIAMETER Server uses the data in this AVP 541 in order to authenticate the mobile node. 543 AVP Format 544 0 1 2 3 545 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 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 AVP Header (AVP Code = 323) 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Data ... 550 +-+-+-+-+-+-+-+-+ 552 AVP Flags 553 The 'M' bit MUST be set. The 'P' bit MAY be set if end to end 554 message integrity is required. The 'H' or 'E' may be set if 555 the AVP is to be encrypted. The 'V', 'H' and 'T' bits MUST NOT 556 be set. 558 Data 559 The data field contains the mobile node's challenge response 560 and is used to authenticate the mobile node. Although any 561 authentication algorithm can be used, all implementations MUST 562 support MD5's prefix+suffix mode, as described in [5]. The 563 formula used to generate the hash is as follow: 565 MD5(Key | Challenge | Key) 567 Where the Key field is the secret shared between the DIAMETER 568 Server and the Mobile Node. The key is concatinated with the 569 Challenge value, which is found in the MIP-Registration-Request 570 AVP. Note that only a portion of the data in the registration 571 request is used for the calculation of the response. The length 572 of the challenge can be found in the MN-FA-Challenge-Length 573 AVP. 575 3.5 MN-to-FA-Key 577 Description 579 This AVP contains the Key generated by the home DIAMETER Server 580 that must be used by the Mobile Node to compute the MN-FA 581 Authentication Extension in the Registration Request [4]. This key 582 is encrypted using the security association the Home AAA DIAMETER 583 Server shared with the Mobile Node. This AVP SHOULD be present in 584 the Home-Agent-MIP-Request. 586 AVP Format 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 AVP Header (AVP Code = 325) 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Reserved | Security Algorithm | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | AAA SPI | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | FA SPI | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Data ... 599 +-+-+-+-+-+-+-+-+ 601 AVP Length 602 The length of this attribute MUST be at least 21. 604 AVP Flags 605 The 'M' bit MUST be set. The 'P' bit MAY be set if end to end 606 message integrity is required. Either the 'H' or 'E' bit MUST 607 be set as this AVP contains keying information. The 'V', 'H' 608 and 'T' bits MUST NOT be set. 610 Security Algorithm 611 The security algorithm field specifies the algorithm that was 612 used to encrypt the session keys. The values are consistent 613 with those found in [15], which also contains the formula used 614 for encryption. The following are currently defined: 616 Algorithm Identifier Name Reference 617 --------------------- ------------------ ------------- 618 2 MD5/prefix+suffix RFC 2002 [14] 619 3 HMAC MD5 RFC 2104 [13] 621 AAA SPI 622 A 32-bit opaque value, indicating the SPI that the mobile node 623 must use to determine the algorithm to use for recovering the 624 FA security information. 626 FA SPI 627 A 32-bit opaque value, which the mobile node MUST use to index 628 all the necessary information recovered from the FA security 629 information after it is decoded. The SPI value MUST be the same 630 as the value in the MN SPI field in section 3.6. 632 Data 633 The data field contains the encrypted key used to create a 634 Mobility Security Association between the mobile node and the 635 foreign agent. 637 3.6 FA-to-MN-Key 639 Description 641 This AVP contains the Key generated by the home DIAMETER Server 642 that must be used by the Foreign Agent to compute the MN-FA 643 Authentication Extension in the Registration Request and Reply 644 [4]. This key is encrypted using the security association the Home 645 AAA DIAMETER Server shared with the Foreign Agent. If the Foreign 646 Agent does not belong to the same administrative domain as the 647 DIAMETER Server, the server uses the security assocation it shares 648 with the DIAMETER server in the foreign agent's administrative 649 domain. This AVP SHOULD be present in the AA-Mobile-Node-Answer. 651 AVP Format 653 0 1 2 3 654 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 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 AVP Header (AVP Code = 326) 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | Reserved | Security Algorithm | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | AAA SPI | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | MN SPI | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Data ... 665 +-+-+-+-+-+-+-+-+ 667 AVP Length 668 The length of this attribute MUST be at least 21. 670 AVP Flags 671 The 'M' bit MUST be set. The 'P' bit MAY be set if end to end 672 message integrity is required. Either the 'H' or 'E' bit MUST 673 be set as this AVP contains keying information. The 'V', 'H' 674 and 'T' bits MUST NOT be set. 676 Security Algorithm 677 The security algorithm field specifies the algorithm that was 678 used to encrypt the session keys. The values are consistent 679 with those found in [15], which also contains the formula used 680 for encryption. The following are currently defined: 682 Algorithm Identifier Name Reference 683 --------------------- ------------------ ------------- 684 2 MD5/prefix+suffix RFC 2002 [14] 685 3 HMAC MD5 RFC 2104 [13] 687 AAA SPI 688 A 32-bit opaque value, indicating the SPI that the foreign 689 agent must use to determine the algorithm to use for recovering 690 the MN security information. 692 MN SPI 693 A 32-bit opaque value, which the foreign agent MUST use to 694 index all the necessary information recovered from the MN 695 security information after it is decoded. The SPI value MUST be 696 the same as the value in the FA SPI field in section 3.5. 698 Data 699 The data field contains the encrypted key used to create a 700 Mobility Security Association between the mobile node and the 701 foreign agent. 703 3.7 FA-to-HA-Key 705 Description 707 This AVP contains the Key generated by the home DIAMETER Server 708 that must be used by the Foreign Agent to compute the FA-HA 709 Authentication Extension in the Registration Request and Reply 710 [4]. This key is encrypted using the security association the Home 711 AAA DIAMETER Server shared with the Foreign Agent. If the Foreign 712 Agent does not belong to the same administrative domain as the 713 DIAMETER Server, the server uses the security association it 714 shares with the DIAMETER server in the foreign agent's 715 administrative domain. This AVP SHOULD be present in the AA- 716 Mobile-Node-Answer. 718 AVP Format 719 0 1 2 3 720 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 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 AVP Header (AVP Code = 328) 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | Reserved | Security Algorithm | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | AAA SPI | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | HA SPI | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Data ... 731 +-+-+-+-+-+-+-+-+ 733 AVP Length 734 The length of this attribute MUST be at least 21. 736 AVP Flags 737 The 'M' bit MUST be set. The 'P' bit MAY be set if end to end 738 message integrity is required. Either the 'H' or 'E' bit MUST 739 be set as this AVP contains keying information. The 'V', 'H' 740 and 'T' bits MUST NOT be set. 742 Security Algorithm 743 The security algorithm field specifies the algorithm that was 744 used to encrypt the session keys. The values are consistent 745 with those found in [15], which also contains the formula used 746 for encryption. The following are currently defined: 748 Algorithm Identifier Name Reference 749 --------------------- ------------------ ------------- 750 2 MD5/prefix+suffix RFC 2002 [14] 751 3 HMAC MD5 RFC 2104 [13] 753 AAA SPI 754 A 32-bit opaque value, indicating the SPI that the foreign 755 agent must use to determine the algorithm to use for recovering 756 the HA security information. 758 HA SPI 759 A 32-bit opaque value, which the foreign agent MUST use to 760 index all the necessary information recovered from the HA 761 security information after it is decoded. The SPI value MUST be 762 the same as the value in the FA SPI field in section 3.8. 764 Data 765 The data field contains the encrypted key used to create a 766 Mobility Security Association between the foreign and the home 767 agent. 769 3.8 HA-to-FA-Key 771 Description 773 This AVP contains the Key generated by the home DIAMETER Server 774 that must be used by the Home Agent to compute the FA-HA 775 Authentication Extension in the Registration Request and Reply 776 [4]. This key is encrypted using the security association the Home 777 AAA DIAMETER Server shared with the Home Agent. If the Home Agent 778 does not belong to the same administrative domain as the DIAMETER 779 Server, the server uses the security association it shares with 780 the DIAMETER server in the home agent's administrative domain. 781 This AVP SHOULD be present in the Home-Agent-MIP-Request. 783 AVP Format 785 0 1 2 3 786 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 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 AVP Header (AVP Code = 329) 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Reserved | Security Algorithm | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | AAA SPI | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | FA SPI | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Data ... 797 +-+-+-+-+-+-+-+-+ 799 AVP Length 800 The length of this attribute MUST be at least 21. 802 AVP Flags 803 The 'M' bit MUST be set. The 'P' bit MAY be set if end to end 804 message integrity is required. Either the 'H' or 'E' bit MUST 805 be set as this AVP contains keying information. The 'V', 'H' 806 and 'T' bits MUST NOT be set. 808 Security Algorithm 809 The security algorithm field specifies the algorithm that was 810 used to encrypt the session keys. The values are consistent 811 with those found in [15], which also contains the formula used 812 for encryption. The following are currently defined: 814 Algorithm Identifier Name Reference 815 --------------------- ------------------ ------------- 816 2 MD5/prefix+suffix RFC 2002 [14] 817 3 HMAC MD5 RFC 2104 [13] 819 AAA SPI 820 A 32-bit opaque value, indicating the SPI that the home agent 821 must use to determine the algorithm to use for recovering the 822 FA security information. 824 HA SPI 825 A 32-bit opaque value, which the home agent MUST use to index 826 all the necessary information recovered from the FA security 827 information after it is decoded. The SPI value MUST be the same 828 as the value in the HA SPI field in section 3.7. 830 Data 831 The data field contains the encrypted key used to create a 832 Mobility Security Association between the foreign and the home 833 agent. 835 3.9 MN-to-HA-Key 837 Description 839 This AVP contains the Key generated by the home DIAMETER Server 840 that must be used by the Mobile Node to compute the MN-HA 841 Authentication Extension in the Registration Request [4]. This key 842 is encrypted using the security association the Home AAA DIAMETER 843 Server shared with the Mobile Node. This AVP SHOULD be present in 844 the Home-Agent-MIP-Request. 846 AVP Format 848 0 1 2 3 849 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 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 AVP Header (AVP Code = 331) 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Reserved | Security Algorithm | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | AAA SPI | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | HA SPI | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Data ... 860 +-+-+-+-+-+-+-+-+ 861 AVP Length 862 The length of this attribute MUST be at least 21. 864 AVP Flags 865 The 'M' bit MUST be set. The 'P' bit MAY be set if end to end 866 message integrity is required. Either the 'H' or 'E' bit MUST 867 be set as this AVP contains keying information. The 'V', 'H' 868 and 'T' bits MUST NOT be set. 870 Security Algorithm 871 The security algorithm field specifies the algorithm that was 872 used to encrypt the session keys. The values are consistent 873 with those found in [15], which also contains the formula used 874 for encryption. The following are currently defined: 876 Algorithm Identifier Name Reference 877 --------------------- ------------------ ------------- 878 2 MD5/prefix+suffix RFC 2002 [14] 879 3 HMAC MD5 RFC 2104 [13] 881 AAA SPI 882 A 32-bit opaque value, indicating the SPI that the mobile node 883 must use to determine the algorithm to use for recovering the 884 HA security information. 886 HA SPI 887 A 32-bit opaque value, which the mobile node MUST use to index 888 all the necessary information recovered from the HA security 889 information after it is decoded. The SPI value MUST be the same 890 as the value in the MN SPI field in section 3.10. 892 Data 893 The data field contains the encrypted key used to create a 894 Mobility Security Association between the mobile node and the 895 home agent. 897 3.10 HA-to-MN-Key 899 Description 901 This AVP contains the Key generated by the home DIAMETER Server 902 that must be used by the Home Agent to compute the MN-HA 903 Authentication Extension in the Registration Request and Reply 904 [4]. This key is encrypted using the security association the Home 905 AAA DIAMETER Server shared with the Home Agent. If the Home Agent 906 does not belong to the same administrative domain as the DIAMETER 907 Server, the server uses the security association it shares with 908 the DIAMETER server in the home agent's administrative domain. 909 This AVP SHOULD be present in the Home-Agent-MIP-Request. 911 AVP Format 913 0 1 2 3 914 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 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 AVP Header (AVP Code = 332) 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Reserved | Security Algorithm | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | AAA SPI | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | MN SPI | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | Data ... 925 +-+-+-+-+-+-+-+-+ 927 AVP Length 928 The length of this attribute MUST be at least 21. 930 AVP Flags 931 The 'M' bit MUST be set. The 'P' bit MAY be set if end to end 932 message integrity is required. Either the 'H' or 'E' bit MUST 933 be set as this AVP contains keying information. The 'V', 'H' 934 and 'T' bits MUST NOT be set. 936 Security Algorithm 937 The security algorithm field specifies the algorithm that was 938 used to encrypt the session keys. The values are consistent 939 with those found in [15], which also contains the formula used 940 for encryption. The following are currently defined: 942 Algorithm Identifier Name Reference 943 --------------------- ------------------ ------------- 944 2 MD5/prefix+suffix RFC 2002 [14] 945 3 HMAC MD5 RFC 2104 [13] 947 AAA SPI 948 A 32-bit opaque value, indicating the SPI that the home agent 949 must use to determine the algorithm to use for recovering the 950 MN security information. 952 HA SPI 953 A 32-bit opaque value, which the home agent MUST use to index 954 all the necessary information recovered from the MN security 955 information after it is decoded. The SPI value MUST be the same 956 as the value in the HA SPI field in section 3.9. 958 Data 959 The data field contains the encrypted key used to create a 960 Mobility Security Association between the mobile node and the 961 home agent. 963 3.11 Mobile-Node-Address 965 Description 967 The Mobile-Node-Address AVP contains the Mobile Node's Home 968 Address. When this AVP has a zero IP Address (0.0.0.0), it is a 969 request that a Home Address be allocated to the Mobile Node. 971 AVP Format 973 0 1 2 3 974 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 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 AVP Header (AVP Code = 333) 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Address... 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 AVP Flags 982 The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending 983 upon the security model used. The 'V', 'T' and the 'P' bits 984 MUST NOT be set. 986 Address 987 The Address field contains the IP address assigned to the 988 Mobile Node, or 0.0.0.0 if one is requested. 990 3.12 Home-Agent-Address 992 Description 994 The Home-Agent-Addess AVP contains the Mobile Node's Home Agent 995 Address. When this AVP has a NULL address (0.0.0.0), it is a 996 request that a Home Agent be allocated to the Mobile Node. If this 997 AVP is set to the NULL address in the AMA message, it is an 998 indication that a Home Agent MUST be allocated in the foreign 999 network. 1001 AVP Format 1003 0 1 2 3 1004 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 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 AVP Header (AVP Code = 334) 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 | Address... 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 AVP Flags 1012 The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending 1013 upon the security model used. The 'V', 'T' and the 'P' bits 1014 MUST NOT be set. 1016 Address 1017 The Address field contains the Home Agent address assigned to 1018 the Mobile Node. If the address is set to 0.0.0.0, the Mobile 1019 Node is requesting that a Home Agent be allocated either in the 1020 foreign network or in its home network. If the address is set 1021 to 255.255.255.255 the Mobile Node is requesting that the Home 1022 Agent be allocated only within its home network. 1024 3.13 Previous-FA-NAI 1026 Description 1028 The Previous-FA-NAI AVP contains the Network Access Identifier of 1029 the Mobile Node's old Foreign Agent. The Mobile Node will include 1030 this information in the Registration Request when it moves it 1031 point of attachment to a new foreign agent under the same 1032 administrative domain as the old FA (identified by the domain part 1033 of the NAI). 1035 When this AVP is present in the AA-Mobile-Node-Request, it 1036 indicates that the local DIAMETER Server overseeing the Foreign 1037 Agent should attempt to return the session key that was previously 1038 allocated to the old Foreign Agent for the Mobile Node. The 1039 session key is identified through the use of the Mobile-Node- 1040 Address AVP, which MUST be present if this extension is present. 1042 This allows the Mobile Node to move from one Foreign Agent to 1043 another within the same administrative domain without having to 1044 send the request back to the Mobile Node's Home DIAMETER Server. 1046 AVP Format 1047 0 1 2 3 1048 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 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 AVP Header (AVP Code = 335) 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | String ... 1053 +-+-+-+-+-+-+-+-+ 1055 AVP Flags 1056 The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending 1057 upon the security model used. The 'V', 'T' and the 'P' bits 1058 MUST NOT be set. 1060 String 1061 The String field contains the Mobile Node's old Foreign Agent's 1062 NAI. 1064 3.14 Foreign-Home-Agent-Available 1066 Description 1068 The Foreign-Home-Agent-Available AVP is added by the AAAF owned by 1069 the same adminitrative domain as the Foreign Agent if it is 1070 willing and able to allocate a Home Agent within the Foreign 1071 network for the Mobile Node. 1073 If this extension is present in the AMR and the Home-Agent-Address 1074 AVP is set to 0.0.0.0, the AAAH MAY allow the AAAF to assign a 1075 Home Agent for the Mobile Node. This is done by including the 1076 Home-Agent-Address AVP with a value of 0.0.0.0 in the AMR. 1078 AVP Format 1080 0 1 2 3 1081 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 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 AVP Header (AVP Code = 335) 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | Integer32 | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 AVP Flags 1089 The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending 1090 upon the security model used. The 'V', 'T' and the 'P' bits 1091 MUST NOT be set. 1093 Integer32 1094 The Integer32 field MUST be set to 1 to inform the AAAH that 1095 the AAAF is able and willing to allocate a Home Agent for the 1096 Mobile Node. 1098 3.15 MN-AAA-SPI 1100 Description 1102 The MN-AAA-SPI is sent in the AA-Mobile-Node-Request by the 1103 Foreign Agent, and contains the SPI value found in the Mobile-IP 1104 MN-AAA Authentication Extension [5]. The SPI can be used by the 1105 AAAH to identify the authentication transform to use with the 1106 Mobile Node, in the event that the Mobile-Node's NAI is not 1107 sufficient. 1109 AVP Format 1111 0 1 2 3 1112 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 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 AVP Header (AVP Code = 336) 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | SPI | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 AVP Flags 1120 The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending 1121 upon the security model used. The 'V', 'T' and the 'P' bits 1122 MUST NOT be set. 1124 Integer32 1125 The Integer32 field contains the SPI value associated with the 1126 Security Association shared between the Mobile Node and the 1127 AAAH. 1129 4.0 Protocol Definition 1131 This section will outline how the DIAMETER Mobile IP Extension can be 1132 used. 1134 4.1 Feature Advertisement/Discovery 1136 As defined in [1], the Reboot-Ind message can be used to inform a 1137 peer about locally supported DIAMETER Extensions. In order to 1138 advertise support of this extension, the Extension-Id AVP must be 1139 transmitted with a value of four (4). 1141 4.2 Inter-Domain Mobile IP 1143 The following diagram is an example of an inter-domain Mobile IP 1144 network. 1146 ISP Home Network 1147 +--------+ +--------+ 1148 | | AMR/A | | 1149 | AAAF |<--------------->| AAAH | 1150 | server | server-server | server | 1151 +--------+ communication +--------+ 1152 / /|\ /|\ 1153 /AMR/A | client-server | HAR/A 1154 / | communication | 1155 |/_ \|/ \|/ 1156 +---------+ +---------+ +---------+ 1157 | Foreign | | Foreign | | Home | 1158 | Agent | | Agent | | Agent | 1159 +---------+ +---------+ +---------+ 1160 /|\ 1161 | Mobile IP 1162 | 1163 \|/ 1164 +--------+ 1165 | Mobile | 1166 | Node | 1167 +--------+ 1169 Figure 1: Inter-Domain Mobility 1171 The AA-Mobile-Node-Request (AMR) is generated by the Foreign Agent 1172 and includes the AVPs defined in section 2.1. The Mobile-Node-Address 1173 AVP's value is copied from the Registration Request's Home Address 1174 field. The Home-Agent-Address AVP's value is copied from the 1175 Registration Request's Home Agent field. The value of the User-Name 1176 AVP [1] is taken from the Mobile-Node-NAI extension as described in 1177 [8]. The request is then forwarded to the Foreign Agent's local 1178 DIAMETER server, known as the AAA-Foreign, or AAAF. 1180 When the AAAF receives the message, it uses the User-Name AVP [1] to 1181 determine whether authentication and authorization can be handled 1182 locally. The User-Name format is consistent with the NAI described in 1183 [6] and the user's domain is used to determine the Mobile Node's home 1184 DIAMETER Server (or AAAH). In the example below, the request cannot 1185 be processed by the AAAF, therefore the request is proxied [9] to the 1186 AAAH. Note that this exchange is only required when the Mobile Node 1187 attempts to gain service with a new Foreign Agent, or if the keys 1188 previously distributed expire. The AAAF MAY include the Proxy-State 1189 AVP in the request, as described in [1], in order to assist it in 1190 keeping Session State Information. 1192 Mobile Node Foreign Agent AAAF AAAH Home Agent 1193 ----------- ------------- ------------ ---------- ---------- 1195 <-------Challenge 1196 Reg-Req(Response)-> 1197 AMR-------------> 1198 AMR------------> 1199 HAR-----------> 1200 <----------HAA 1201 <-----------AMA 1202 <------------AMA 1203 <-------Reg-Reply 1205 Figure 2: Mobile IP/DIAMETER Message Exchange 1207 The AAAH uses the security association shared between the itself and 1208 the Mobile Node in order to validate the MN-FA-Response. If the 1209 response is invalid, the AAAH returns the AA-Mobile-Node-Answer (AMA, 1210 see section 2.2) with a Result-Code set to the appropriate value. 1212 If the Mobile Node was successfully authenticated, the AAAH checks 1213 whether the Home-Agent-Address AVP specified a Home Agent. If one was 1214 specified, the AAAH must validate the address to ensure that it is a 1215 known Home Agent. If no Home Agent was specified the AAAH SHOULD 1216 allocate one on behalf of the Mobile Node. This can be done in a 1217 variety of ways, including using a load balancing algorithm in order 1218 to keep the load on all Home Agents equal. The actual algorithm used 1219 and the method of discovering the Home Agents is outside of this 1220 specification, but the method proposed in [4] can be used. 1222 If the AMR's Mobile-Node-Address AVP did not specify an address, the 1223 AAAH has the option of assigning an address for the Mobile Node, or 1224 it can leave this up to the Home Agent. This is purely a local policy 1225 decision. 1227 The AAAH then proceeds to generate three short-lived session keys; 1228 one which is shared between the Mobile Node and the Home Agent, one 1229 between the Mobile Node and the Foreign Agent, and one between the 1230 Foreign Agent and the Home Agent. 1232 The keys destined for the Mobile Node are encrypted either using the 1233 Mobile Node's secret or its public key [1, 9]. The keys destined for 1234 the Foreign Agent are encrypted either using the secret shared 1235 between the AAAH and the AAAF, or using public key cryptography [1, 1236 9]. The keys destined for the Home Agent can be either encrypted 1237 using the secret it shares with the AAAH. The Session-Timeout AVP is 1238 included and contains the number of seconds before the session keys 1239 expire. A value of zero indicates that the session keys have no 1240 expiration. 1242 Note that this extension requires a departure from the existing SPI 1243 usage described in [4]. The AAAH generates SPI values for the 1244 Mobility Agents as opposed to a receiver choosing its own SPI value. 1245 The SPI values are used as Key Identifiers, meaning that each short- 1246 lived session key has its own SPI value and since two nodes share a 1247 session key they share an SPI as well. 1249 Suppose a Mobile Node and a Foreign Agent share a key that was 1250 created by the AAAH. The AAAH also generated a corresponding SPI 1251 value of 37,496. All Mobile-Foreign Authentication extensions must be 1252 computed by either entity using the shared session key would then 1253 include the SPI value of 37,496. 1255 The AAAH then sends a Home-Agent-MIP-Request (HAR) to the assigned or 1256 requested Home Agent. The HAR contains the MIP-Registration-Request 1257 as well as the keys destined for the Home Agent (HA-to-MN-Key, HA- 1258 to-FA-Key AVPs) and the Mobile Node (MN-to-FA-Key, MN-to-HA-Key AVP). 1259 The Mobile-Node-Address AVP contains an address if the Mobile Node 1260 specified a home address or if the AAAH assigned an address, but no 1261 address would be specified if the Home Agent were to assign one. 1263 Note that the keys generated for the Foreign Agent, the SPIs and the 1264 Session Timeout will have to be propagated to the AAAF in a future 1265 message. The AAAH can use one of two suggested methods: 1267 1. Maintain Session State information within the AAAH, based on 1268 the Session Identifier. When the Response from the Home Agent is 1269 received, the AAAH looks up the FA keys, SPI and Session Timeout 1270 and includes them in the DIAMETER message bound for the AAAF. 1272 2. Add the FA keys within the Proxy-State AVP [1]. The Home Agent 1273 MUST include the same Proxy-State AVP in the response. The AAAH 1274 can then pull the information from the Proxy-State AVP and include 1275 them in the message targeted for the AAAF. 1277 Note that the method used will not create any interoperability issues 1278 given that the decision is purely local and the Home Agent does not 1279 attempt to decode the Proxy-State AVP. 1281 The Home Agent processes the DIAMETER Home-Agent-MIP-Request as well 1282 as the embedded Mobile IP Registration Request. If both are 1283 successfull, the Home Agent creates the Mobile IP Registration Reply, 1284 and furthermore includes the keying material to be used by the Mobile 1285 Node (MN-to-FA-Key, MN-to-HA-Key) in the MIP-Registration-Reply AVP. 1286 If the address in the Mobile-Node-Address AVP in the request was set 1287 to zeros (0.0.0.0), the Home Agent must assign an address for the 1288 Mobile Node. The Result-Code AVP is included and the Home-Agent-MIP- 1289 Answer is sent to the AAAH. 1291 The AAAH then issues a AA-Mobile-Node-Answer to the AAAF which 1292 includes the MIP-Registration-Reply, Result-Code and the Mobile- 1293 Node-Address AVP. As mentioned earlier, the AAAH must be able to find 1294 the previously created information destined for the AAAF, and add 1295 them in the response. The AVPs are must be added are the FA-to-MN- 1296 Key, FA-to-HA-Key and the Session-Timeout AVPs. 1298 Upon receipt of the successful AA-Mobile-Node-Answer the AAAF 1299 decrypts the FA-to-MN-Key and the FA-to-HA-Key AVPs. These keys are 1300 then re-encrypted using the DIAMETER secret [1] or via end-to-end 1301 encryption [9], unless IPSEC's ESP [10] is used between the Foreign 1302 Agent and the AAAF. The message is transmitted to the Foreign Agent. 1304 The Foreign Agent, upon receipt of the AA-Mobile-Node-Answer, 1305 decrypts the appropriate KEY AVPs, and processes the Mobile IP 1306 Registration Reply which is then forwarded to the Mobile Node. 1308 From this point on, all Registration Request and Replies need rely on 1309 the DIAMETER proxy chain, the Foreign Agent can contact the Home 1310 Agent directly using the keys which were previously distributed. This 1311 can continue until the session keys expire, as indicated in the 1312 Session-Timeout AVP [1]. 1314 The following is an example of subsequent Mobile IP message exchange. 1316 Mobile Node Foreign Agent Home Agent 1317 ----------- ------------- ---------- 1319 Reg-Req(MN-FA-Auth, MN-HA-Auth)--------> 1321 Reg-Req(MN-HA-Auth, FA-HA-Auth)--------> 1323 <--------Reg-Rep(MN-HA-Auth, FA-HA-Auth) 1325 <--------Reg-Rep(MN-HA-Auth, MN-FA-Auth) 1327 Figure 3: Mobile IP Message Exchange 1329 Note that subsequent registrations MUST use the MN-FA, FA-HA and MN- 1330 FA Authentication extensions [4], using the keys generated by the 1331 AAAH. 1333 4.3 Allocation of Home Agent in Foreign Network 1335 When the AAAF receives the AMR message, it can add the Foreign-Home- 1336 Agent-Available AVP to inform the AAAH that it is able and willing to 1337 assign a Home Agent for the Mobile Node. The AAAH will only allow 1338 this if the Home-Agent-Address in the AMR is set to zero (0). The 1339 AAAH does this by sending the AMA message to the AAAF with the Home- 1340 Agent-Address AVP set to zero (0). The AMA message still includes all 1341 of the keying information that was previously discussed, except that 1342 the keys for the Home Agent are encrypted using the security 1343 association the AAAH shares with the AAAF. 1345 ISP Home Network 1346 +--------+ +--------+ 1347 | | AMR/A | | 1348 | AAAF |<--------------->| AAAH | 1349 | server | server-server | server | 1350 +--------+ communication +--------+ 1351 / /|\ 1352 HAR/A /AMR/A | client-server 1353 / | communication 1354 |/_ \|/ 1355 +---------+ +---------+ 1356 | Home | | Foreign | 1357 | Agent | | Agent | 1358 +---------+ +---------+ 1359 /|\ 1360 | Mobile IP 1361 | 1362 \|/ 1363 +--------+ 1364 | Mobile | 1365 | Node | 1366 +--------+ 1367 Figure 4: Home Agent allocated in Foreign Domain 1369 Upon receipt of such a message, the AAAF issues the HAR message to 1370 the Home Agent. Upon receipt of the response from the Home Agent the 1371 AAAF issues the AMA message to the Foreign Agent in the same method 1372 described earlier. 1374 Mobile Node Foreign Agent AAAF Home Agent AAAH 1375 ----------- ------------- ------------- ---------- ---------- 1377 <-------Challenge 1378 Reg-Req(Response)-> 1379 AMR-------------> 1380 AMR--------------------------> 1381 <------------------------AMA 1382 HAR-------------> 1383 <----------HAA 1384 <------------AMA 1385 <-------Reg-Reply 1386 Figure 5: Mobile IP/DIAMETER Message Exchange 1388 If the Mobile Node moves to another Foreign Network, which it detects 1389 from the Router Advertisement message, it can either request to keep 1390 the same Home Agent within the old foreign network, or it can request 1391 that a new one be assigned. If the Home-Agent-Address AVP is set to a 1392 value, it indicates that the same Home Agent should be used. 1394 In this case the new AAAF would issue the AMR message towards the 1395 Mobile Node's AAAH, which would create the keys as previously 1396 defined. In this case all of the keys destined for the Home Agent 1397 would be encrypted using the security association it shares with the 1398 old Foreign Network's AAAF, while the keys for the Foreign Agent 1399 would be encrypted using the security association shared with the new 1400 Foreign Network's AAAF. 1402 4.4 DIAMETER Session Termination 1404 For DIAMETER Servers that maintain Mobile Node state information, 1405 each session has a specific lifetime, which is derived from the 1406 Session-Timeout AVP. Therefore a DIAMETER Server can release 1407 resources for a Mobile Node once the time has expired. However, it 1408 would be desirable for the DIAMETER Server to be notified when a 1409 session is terminated, which would allow it to release resources when 1410 they are no longer used. 1412 The Mobile-Node-Termination-Ind message is sent by a DIAMETER Client, 1413 be it a Foreign or Home Agent, to inform a DIAMETER Server that a 1414 session has been terminated. The MTI message MAY be sent by a 1415 DIAMETER Server to a client in order to request that the Mobile 1416 Node's session be terminated. 1418 5.0 Acknowledgements 1419 The authors would like to thank Nenad Trifunovic, Tony Johansson and 1420 Pankaj Patel for their participation in the Document Reading Party. 1421 The authors would also like to thank the participants of TIA's TR45.6 1422 working group for their valuable feedback. 1424 6.0 IANA Considerations 1426 The numbers for the Command Code AVPs (section 2) is taken from the 1427 numbering space defined for Command Codes in [1]. The numbers for the 1428 various AVPs defined in section 3 were taken from the AVP numbering 1429 space defined in [1]. The numbering for the AVP and Command Codes 1430 MUST NOT conflict with values specified in [1] and other DIAMETER 1431 related Internet Drafts. 1433 7.0 References 1435 [1] Calhoun, Rubens, "DIAMETER Base Protocol", Internet-Draft, 1436 draft-calhoun-diameter-10.txt, Work in Progress, 1437 October 1999. 1438 [2] Calhoun, Zorn, Pan, "DIAMETER Framework", Internet- 1439 Draft, draft-calhoun-diameter-framework-04.txt, 1440 Work in Progress, October 1999. 1441 [3] P. Calhoun, G. Montenegro, C. Perkins, "Tunnel Establishment 1442 Protocol", draft-ietf-mobileip-calhoun-tep-01.txt, 1443 Work in Progress, March 1998. 1444 [4] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1445 1996. 1446 [5] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response 1447 Extensions", draft-ietf-mobileip-challenge-04.txt, Work in 1448 Progress, October 1999. 1449 [6] Aboba, Beadles "The Network Access Identifier." RFC 2486. 1450 January 1999. 1451 [7] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", 1452 RFC 2477, January 1999. 1453 [8] P. Calhoun, C. Perkins, "Mobile IP Network Address Identifier 1454 Extension", draft-ietf-mobileip-mn-nai-05.txt, 1455 Work in Progress, October 1999. 1456 [9] P. Calhoun, W. Bulley, "DIAMETER Secure Proxy Extensions", 1457 draft-calhoun-diameter-proxy-03.txt, Work in Progress, 1458 October 1999. 1459 [10] Kent, Atkinson, "IP Encapsulating Security Payload (ESP)", 1460 RFC 2406, November 1998. 1461 [11] S. Bradner, "Key words for use in RFCs to Indicate 1462 Requirement Levels", BCP 14, RFC 2119, March 1997. 1463 [12] Arkko, Calhoun, Patel, Zorn, "DIAMETER Accounting 1464 Extension", draft-calhoun-diameter-accounting-00.txt, 1465 IETF Work in Progress, September 1999. 1466 [13] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing 1467 for Message Authentication. RFC 2104, February 1997. 1468 [14] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1469 1996. 1470 [15] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile IP", 1471 draft-ietf-mobileip-aaa-keys-00.txt, IETF Work in Progress, 1472 June 1999. 1474 8.0 Authors' Addresses 1476 Questions about this memo can be directed to: 1478 Pat R. Calhoun 1479 Network and Security Research Center, Sun Labs 1480 Sun Microsystems, Inc. 1481 15 Network Circle 1482 Menlo Park, California, 94025 1483 USA 1485 Phone: 1-650-786-7733 1486 Fax: 1-650-786-6445 1487 E-mail: pcalhoun@eng.sun.com 1489 Charles E. Perkins 1490 Nokia Research Center 1491 313 Fairchild Drive 1492 Mountain View, California 94043 1493 USA 1495 Phone: +1-650 625-2986 1496 Fax: +1 650 691-2170 1497 E-Mail: charliep@iprg.nokia.com 1499 9.0 Full Copyright Statement 1501 Copyright (C) The Internet Society (1999). All Rights Reserved. 1503 This document and translations of it may be copied and furnished 1504 to others, and derivative works that comment on or otherwise 1505 explain it or assist in its implmentation may be prepared, copied, 1506 published and distributed, in whole or in part, without 1507 restriction of any kind, provided that the above copyright notice 1508 and this paragraph are included on all such copies and derivative 1509 works. However, this docu- ment itself may not be modified in any 1510 way, such as by removing the copyright notice or references to the 1511 Internet Society or other Inter- net organizations, except as needed 1512 for the purpose of developing Internet standards in which case 1513 the procedures for copyrights defined in the Internet Standards 1514 process must be followed, or as required to translate it into 1515 languages other than English. The limited permis- sions granted 1516 above are perpetual and will not be revoked by the Internet 1517 Society or its successors or assigns. This document and the 1518 information contained herein is provided on an "AS IS" basis and 1519 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 1520 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1521 LIMITED TO ANY WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN 1522 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1523 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."