idnits 2.17.1 draft-ietf-aaa-diameter-mobileip-08.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 41 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 42 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 18 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 == Line 149 has weird spacing: '... allows mobil...' == 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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: An AAA Home server (AAAH) and AAA foreign server (AAAF) which supports the Mobile-IP authentication application MAY maintain session-state or MAY be session-stateless. AAA redirect agents and AAA relay agents MUST not maintain session-state. AAAH, AAAF, proxies and relays agents MUST maintain transaction state. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The following tables presents the AVPs defined in this document, and specifies in which Diameter messages they MAY, or MAY NOT be present. Note that AVPs that can only be present within a Grouped AVP are not represented in this table. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2001) is 8190 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '10' is defined on line 1722, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1728, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1734, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-08 ** Obsolete normative reference: RFC 2434 (ref. '2') (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 2977 (ref. '3') ** Obsolete normative reference: RFC 2002 (ref. '4') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 3012 (ref. '5') (Obsoleted by RFC 4721) ** 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 (-04) exists of draft-ietf-aaa-diameter-cms-sec-03 -- Possible downref: Normative reference to a draft: ref. '9' ** Obsolete normative reference: RFC 2406 (ref. '10') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2279 (ref. '12') (Obsoleted by RFC 3629) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '13') == Outdated reference: A later version (-17) exists of draft-ietf-aaa-diameter-nasreq-08 == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-aaa-key-08 -- Possible downref: Normative reference to a draft: ref. '15' ** Downref: Normative reference to an Informational RFC: RFC 3141 (ref. '16') -- Possible downref: Non-RFC (?) normative reference: ref. '17' ** Obsolete normative reference: RFC 1750 (ref. '18') (Obsoleted by RFC 4086) Summary: 17 errors (**), 0 flaws (~~), 14 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AAA Working Group Pat R. Calhoun 3 Internet-Draft Black Storm Networks 4 Category: Standards Track Charles E. Perkins 5 Nokia Research Center 6 November 2001 8 Diameter Mobile IPv4 Application 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at: 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at: 29 http://www.ietf.org/shadow.html. 31 Distribution of this memo is unlimited. 33 Copyright (C) The Internet Society 2001. All Rights Reserved. 35 Abstract 37 This document specifies a Diameter application that allows a Diameter 38 server to authenticate, authorize and collect accounting information 39 for Mobile IPv4 services rendered to a mobile node. Combined with 40 the Inter-Realm capability of the base protocol, this application 41 allows mobile nodes to receive service from foreign service 42 providers. Diameter Accounting messages will be used by the Foreign 43 and Home agents to transfer usage information to the Diameter 44 servers. 46 Table of Contents 48 1.0 Introduction 49 1.1 Requirements language 50 1.2 Inter-Realm Mobile IP 51 1.3 Support for Mobile IP Handoffs 52 1.4 Allocation of Home Agent in Foreign Network 53 1.5 Co-located Mobile Node 54 1.6 Diameter Session Termination 55 1.7 Advertising Application support 56 1.8 Fast Handoff support 57 2.0 Command-Code Values 58 2.1 AA-Mobile-Node-Request 59 2.2 AA-Mobile-Node-Answer 60 2.3 Home-Agent-MIP-Request 61 2.4 Home-Agent-MIP-Answer 62 3.0 Result-Code AVP Values 63 3.1 Transient Failures 64 3.2 Permanent Failures 65 4.0 Diameter AVPs 66 4.1 MIP-Reg-Request AVP 67 4.2 MIP-Reg-Reply AVP 68 4.3 MIP-Mobile-Node-Address AVP 69 4.4 MIP-Home-Agent-Address AVP 70 4.5 MIP-Feature-Vector AVP 71 4.6 MIP-MN-AAA-Auth AVP 72 4.6.1 MIP-MN-AAA-SPI AVP 73 4.6.2 MIP-Auth-Input-Data-Length AVP 74 4.6.3 MIP-Authenticator-Length AVP 75 4.6.4 MIP-Authenticator-Offset AVP 76 4.7 MIP-FA-Challenge AVP 77 4.8 MIP-Foreign-Agent-Host AVP 78 4.9 MIP-Filter-Rule AVP 79 4.10 MIP-Candidate-Home-Agent-Host 80 5.0 Key Distribution Center 81 5.1 Key Material vs. Session Key 82 5.2 Distributing the Mobile-Home Session Key 83 5.3 Distributing the Mobile-Foreign Session Key 84 5.4 Distributing the Foreign-Home Session Key 85 5.5 Key Distribution Example 86 6.0 Key Distribution Center (KDC) AVPs 87 6.1 MIP-FA-to-MN-Key AVP 88 6.2 MIP-FA-to-HA-Key AVP 89 6.3 MIP-HA-to-FA-Key AVP 90 6.4 MIP-HA-to-MN-Key AVP 91 6.5 MIP-MN-to-FA-Key AVP 92 6.6 MIP-MN-to-HA-Key AVP 93 6.7 MIP-Session-Key AVP 94 6.8 MIP-Algorithm-Type AVP 95 6.9 MIP-Replay-Mode AVP 96 6.10 MIP-FA-to-MN-SPI 97 6.11 MIP-FA-to-HA-SPI 98 6.12 MIP-Key-Material AVP 99 6.13 MIP-Key-Lifetime AVP 100 7.0 Accounting AVPs 101 7.1 Accounting-Input-Extended-Octets AVP 102 7.2 Accounting-Output-Extended-Octets AVP 103 7.3 Accounting-Session-Time AVP 104 7.4 Accounting-Input-Extended-Packets AVP 105 7.5 Accounting-Output-Extended-Packets AVP 106 8.0 AVP Table 107 8.1 Mobile IP Command AVP Table 108 8.2 Accounting AVP Table 109 9.0 Acknowledgements 110 10.0 IANA Considerations 111 10.1 Command Codes 112 10.2 AVP Codes 113 10.3 Result-Code AVP Values 114 10.4 MIP-Feature-Vector AVP Values 115 10.5 MIP-Algorithm-Type AVP Values 116 10.6 MIP-Replay-Mode AVP Values 117 10.7 Application Identifier 118 11.0 Security Considerations 119 12.0 Acknowledgements 120 13.0 References 121 14.0 Authors' Addresses 122 15.0 Full Copyright Statement 123 16.0 Expiration Date 125 1.0 Introduction 127 Mobile IP, as defined in [4], defines a method that allows a Mobile 128 Node to change its point of attachment to the Internet with minimal 129 service disruption. Mobile IP does not provide any specific support 130 for mobility across disparate administrative domains, and therefore 131 does not specify how usage can be accounted for, which has limited 132 the applicability of Mobile IP in a IPv4 commercial deployment. The 133 Mobile IP specification as defined in [4] recommends mobile nodes to 134 have a static home address and a home agent. However this may not be 135 always possible in certain deployment scenarios. Recent developments 136 in areas that impact IP mobility in the IETF allow Mobile IP [4] to 137 work just as well when mobile nodes do not have a static home agent 138 and home address. Recent specification [8] allows a mobile node to 139 use its NAI instead of its home address, which better accommodates 140 current administrative practice. 142 This document specifies Application 4 to the Diameter base protocol 143 [1] that allows a Diameter server to authenticate, authorize and 144 collect accounting information for Mobile IPv4 services rendered to a 145 mobile node. This application MUST NOT be used in conjunction with 146 the Mobile IPv6 protocol. 148 Combined with the Inter-Realm capability of the base protocol, this 149 application allows mobile nodes to receive service from foreign 150 service providers. The Diameter Accounting messages will be used by 151 the Foreign and Home agents to transfer usage information to the 152 Diameter servers. 154 The Mobile IP protocol [4] specifies a security model that requires 155 that mobile nodes and home agents share a pre-existing security 156 association, which leads to scaling and configuration issues. This 157 specification defines Diameter functions that allow the AAA server to 158 act as a Key Distribution Center (KDC), whereby dynamic session keys 159 are created and distributed to the mobility entities for the purposes 160 of securing Mobile IP Registration messages. 162 As with the Diameter base protocol, AAA servers implementing the 163 Mobile IP application can process users' identities supplied in a 164 Network Access Identifier (NAI) format [6], which is used for 165 Diameter message routing purposes. Mobile nodes include their NAI in 166 Registration messages, as defined in [8]. The use of the NAI is 167 consistent with the roaming model defined by the ROAMOPS Working 168 Group [7]. 170 An AAA Home server (AAAH) and AAA foreign server (AAAF) which 171 supports the Mobile-IP authentication application MAY maintain 172 session-state or MAY be session-stateless. AAA redirect agents and 173 AAA relay agents MUST not maintain session-state. AAAH, AAAF, proxies 174 and relays agents MUST maintain transaction state. 176 Given the nature of Mobile IP, a re-authentication can only be 177 initiated by a mobile node, which does not participate in the 178 Diameter message exchanges. Therefore the Diameter base protocol's 179 server initiated re-auth does not apply to this application 181 The Diameter Mobile-IP Application meets the requirements specified 182 in [3, 16]. Later subsections in this introductory section provide 183 some examples and message flows of the Mobile IP and Diameter 184 messages that occur when a Mobile Node requests service in a foreign 185 network. In this document, the role of the "attendant" [3] is 186 performed by either the home agents (for co-located mobile nodes) or 187 foreign agents for the Mobile-IP Application, and these terms will be 188 used interchangeably. 190 1.1 Requirements language 192 In this document, the key words "MAY", "MUST", "MUST NOT", 193 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 194 interpreted as described in [11]. 196 1.2 Inter-Realm Mobile IP 198 When a Mobile Node node requests service by issuing a Registration 199 Request to the foreign agent, the foreign agent creates the AA- 200 Mobile-Node-Request (AMR) message, which includes the AVPs defined in 201 section 2.1. The Home Address, Home Agent, Mobile Node NAI and other 202 important fields are extracted from the registration messages for 203 possible inclusion as Diameter AVPs. The AMR message is then 204 forwarded to the local Diameter server, known as the AAA-Foreign, or 205 AAAF. 207 Visited Realm Home Realm 208 +--------+ +--------+ 209 |abc.com | AMR/AMA |xyz.com | 210 | AAAF |<------------------->| AAAH | 211 +->| server | server-server | server | 212 | +--------+ communication +--------+ 213 | ^ ^ 214 | AMR/AMA | client-server | HAR/HAA 215 | | communication | 216 v v v 217 +---------+ +---------+ +---------+ 218 | Foreign | | Foreign | | Home | 219 | Agent | | Agent | | Agent | 220 +---------+ +---------+ +---------+ 221 ^ 222 | Mobile IP 223 | 224 v 225 +--------+ 226 | Mobile | 227 | Node | mn@xyz.com 228 +--------+ 229 Figure 1: Inter-Realm Mobility 231 Upon receiving the AMR, the AAAF follows the procedures outlined in 232 [1] to determine whether the AMR should be processed locally, or if 233 it should be forwarded to another Diameter Server, known as the AAA- 234 Home, or AAAH. Figure 1 shows an example in which a mobile node 235 (mn@xyz.com) requests service from a foreign provider (abc.com). The 236 request received by the AAAF is forwarded to xyz.com's AAAH server. 238 Figure 2 shows the message flows involved when the foreign agent 239 invokes the AAA infrastructure to request that a mobile node be 240 authenticated and authorized. Note that it is not required that the 241 foreign agent invoke AAA services every time a Registration Request 242 is received from the mobile, but rather only when the prior 243 authorization from the AAAH expires. The expiration time of the 244 authorization (and session keys, if allocated by the AAA server) is 245 communicated through the Authorization-Lifetime AVP in the AA-Mobile- 246 Node-Answer (AMA, see section 2.2) from the AAAH. 248 Mobile Node Foreign Agent AAAF AAAH Home Agent 249 ----------- ------------- ------------ ---------- ---------- 250 Advertisement & 251 <--------- Challenge 253 Reg-Req&MN-AAA ----> 255 AMR------------> 256 Session-Id = foo 258 AMR------------> 259 Session-Id = foo 261 HAR-----------> 262 Session-Id = bar 264 <----------HAA 265 Session-Id = bar 267 <-----------AMA 268 Session-Id = foo 270 <------------AMA 271 Session-Id = foo 273 <-------Reg-Reply 275 Figure 2: Mobile IP/Diameter Message Exchange 277 The foreign agent (as shown in Figure 2) MAY provide a challenge, 278 which gives it direct control over the replay protection in the 279 Mobile IP registration process, as described in [5]. The mobile node 280 includes the Challenge and MN-AAA authentication extension to enable 281 authorization by AAAH. If the authentication data supplied in the 282 MN-AAA extension is invalid, AAAH returns the response (AMA) with the 283 Result-Code AVP set to DIAMETER_AUTHENTICATION_REJECTED. 285 In the event that the AMR generated by the FA is for a session that 286 has was previously authorized by the AAAH, it MUST include the 287 Destination-Host AVP, with the identity of the AAAH. The AAAH's 288 identity can be retrieved from the Origin-Host AVP in the last AMA 289 received for the session. 291 If the Mobile Node was successfully authenticated, the AAAH checks if 292 the Home Agent was located in the foreign realm, by checking the 293 Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. If 294 the flag is enabled, then the Home Agent is located in the foreign 295 realm then AAAH sends an HAR message to AAAF which contains a MIP- 296 Reg-Request AVP. 298 If the Home Agent was not located in the foreign realm, the AAAH 299 checks for the MIP-Home-Agent-Address AVP. If one was specified, the 300 AAAH checks that the address is that of a known Home Agent, and one 301 that the Mobile Node is allowed to request, and the Home Agent's 302 identity is included in the Destination-Host AVP. If no Home Agent 303 was specified, and if the MIP-Feature-Vector has the Home-Agent- 304 Requested flag set, and if allowed by policy in the home realm, the 305 AAAH SHOULD allocate a home agent on behalf of the Mobile Node. This 306 can be done in a variety of ways, including using a load balancing 307 algorithm in order to keep the load on all home agents equal. The 308 actual algorithm used and the method of discovering the home agents 309 is outside the scope of this specification. 311 The AAAH then sends an Home-Agent-MIP-Request (HAR), which contains 312 the Mobile IP Registration Request message data encapsulated in the 313 MIP-Reg-Request AVP, to the assigned or requested Home Agent. The 314 AAAH MAY allocate a home address for the mobile node, while the Home 315 Agent MUST support home address allocation. In the event the AAAH 316 handles address allocation, it includes it in a MIP-Mobile-Node- 317 Address AVP within the HAR. The absence of this AVP informs the Home 318 Agent to perform the allocation. 320 For new sessions, the AAAH MUST create an accounting session 321 identifier, which is added to the Accounting-Multi-Session-Id AVP in 322 the HAR message sent to the home agent. 324 During the creation of the HAR, the AAAH MUST use a different session 325 identifier than the one used in the AMR/AMA (see figure 2). Of 326 course, an AAAH MUST use the same session identifier for all HARs 327 initiated on behalf of a given mobile node's session. A mobile node's 328 session is identified via its identity in the User-Name AVP, the MIP- 329 Mobile-Node-Address and MIP-Home-Agent-Address AVPs. This is 330 necessary in order to allow the session state machine, defined in the 331 base protocol [1], to be used unmodified with this application. 332 Therefore, an STR from a foreign agent would free the session from 333 the foreign agent, but not the one towards the home agent (see figure 334 3). 336 STR, Session-Id = foo STR, Session-Id = bar 337 ---------------------> <-------------------- 338 +----+ +------+ +------+ +----+ 339 | FA | | AAAF | | AAAH | | HA | 340 +----+ +------+ +------+ +----+ 341 <--------------------- ---------------------> 342 STA, Session-Id = foo STA, Session-Id = bar 343 Figure 3: Session Termination and Session Identifiers 345 Upon receipt of the HAR, the Home Agent first processes the Diameter 346 message. The Home Agent processes the MIP-Reg-Request AVP and creates 347 the Registration Reply, encapsulating it within the MIP-Reg-Reply 348 AVP. If a home address is needed, the Home Agent MUST assign one and 349 include the address in both the Registration Reply and within the 350 MIP-Mobile-Node-Address AVP. The Accounting-Multi-Session-Id AVP in 351 the HAR MUST be included in the HAA, which is then forwarded to the 352 AAAH. 354 Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer 355 (AMA) message, includes the Accounting-Multi-Session-Id that was 356 present in the HAA, and the MIP-Home-Agent-Address, MIP-Mobile-Node- 357 Address AVPs in the AMA message, enabling appropriate firewall 358 controls for the penetration of tunneled traffic between the Home 359 Agent and the Mobile Node. 361 The AAAF is responsible for ensuring that the AMA message is properly 362 forwarded to the correct foreign agent. 364 1.3 Support for Mobile IP Handoffs 366 Given the nature of Mobile IP, a mobile node MAY receive service from 367 many foreign agents during a period of time. However, the home realm 368 should not view these handoffs as different sessions, since this 369 could affect billing systems. Furthermore, many foreign agents do not 370 communicate, which makes it quite difficult for AAA information to be 371 exchanged between these entities. Therefore, it MUST be assumed that 372 a foreign agent is not aware that a registration request from a 373 mobile node has been previously authorized. 375 The first registration request from a mobile node will therefore 376 cause an AMR to be sent to its AAAF. The AMR will include a new 377 session identifier, and MAY even be sent to a different AAAF in the 378 visited network. It is also quite likely that the AMR will be 379 received by a different AAAH. 381 Since the new AAAH in the home network MAY not have access to the 382 session identifier that was used by the old AAAH, it is necessary for 383 the resulting HAR received by the HA to be identified as a 384 continuation of an existing session. If the HA receives an HAR for a 385 mobile node, with a new session identifier, and the HA can guarantee 386 that this request is to extend service for an existing service, then 387 the HA MUST be able to modify its internal session state information 388 to reflect the new AAAH and session identifier. The HA MUST also 389 issue an STR message with the old session identifier to the AAAH it 390 was communicating with when using the old session identifier. 392 It is necessary for accounting records to have some commonality 393 across handoffs in order for correlation to occur. Therefore, in the 394 event that a home agent receives an HAR with a different Accounting- 395 Multi-Session-id AVP (and obviously a different Session-Id AVP), the 396 home agent MUST send an HAA with the Accounting-Multi-Session-Id AVP 397 that was received by the AAAH in the first HAR for the mobile's 398 session. This modified Accounting-Multi-Session-Id AVP will be 399 returned to the foreign agent by the AAAH in the AMA. Both the 400 foreign and home agents MUST include the Accounting-Multi-Session-Id 401 in the accounting messages. 403 ACR, Session-Id = foo ACR, Session-Id = bar 404 Accounting-Multi-Session-Id = a Accounting-Multi-Session-Id = a 405 ---------------------> <-------------------- 406 +----+ +------+ +------+ +----+ 407 | FA | | AAAF | | AAAH | | HA | 408 +----+ +------+ +------+ +----+ 409 <--------------------- ---------------------> 410 ACA, Session-Id = foo ACA, Session-Id = bar 412 Figure 4: Accounting messages w/ Mobile IP Application 414 1.4 Allocation of Home Agent in Foreign Network 416 The Diameter Mobile IP application allows a Home Agent to be 417 allocated in a foreign network, as required in [3, 16]. When a 418 foreign agent detects that the mobile node has a home agent address 419 equal to 0.0.0.0 or 255.255.255.255 in the Registration Request 420 message, it MUST add a MIP-Feature-Vector AVP with the Home-Agent- 421 Requested flag set to one. If the home agent address is equal to 422 255.255.255.255, then the foreign agent also MUST set the Home- 423 Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home 424 agent address is set to 0.0.0.0, the foreign agent MUST set the Home- 425 Address-Allocatable-Only-in-Home-Realm flag equal to zero. 427 When the AAAF receives a AMR message with the Home-Agent-Requested 428 flag set to one, and the Home-Address-Allocatable-Only-in-Home-Realm 429 flag equal to zero, AAAF MAY set the Foreign-Home-Agent-Available 430 flag in the MIP-Feature-Vector AVP to inform the AAAH that it is 431 willing and able to assign a Home Agent for the Mobile Node. When 432 doing so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host 433 AVP, containing the identity of the home agent that would be assigned 434 to the mobile node. 436 In the event that the mobile node requests a home agent in the 437 foreign network, and the AAAF authorizes its use, the AAAF MUST set 438 the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. 439 This could happen when the AAA request is sent to "extend" a mobile 440 node's current session. 442 When the AAAH receives a AMR message, it first checks the 443 authentication data supplied by the mobile node, according to the 444 MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether 445 to authorize the mobile node. If the AMR indicates that the AAAF has 446 offered to allocate a home agent for the mobile node, then the AAAH 447 must decide whether its local policy would allow the user to have a 448 Home Agent in the foreign network. If so, and after checking 449 authorization from the data in the AMR message, the AAAH sends the 450 HAR message to the AAAF that does not contain the MIP-Home-Agent- 451 Address, but includes the Destination-Host AVP set to the value of 452 the AMR's MIP-Candidate-Home-Agent-Host AVP. 454 If the HA hasn't yet been allocated by the foreign domain, the HAR 455 sent by the AAAH back to the foreign realm will not necessarily be 456 received by the same AAAF which sent the AMR. 458 Visited Home 459 Realm Realm 460 +--------+ ------- AMR -------> +--------+ 461 | AAAF | <------ HAR -------- | AAAH | 462 | | | | 463 +--->| server | ------- HAA -------> | server | 464 | +--------+ <------ AMA -------- +--------+ 465 | ^ | 466 | | | 467 HAR/HAA | AMR | | AMA 468 v | v 469 +---------+ +---------+ 470 | Home | | Foreign | 471 | Agent | | Agent | 472 +---------+ +---------+ 473 ^ 474 +--------+ | 475 | Mobile |<----------+ 476 | Node | Mobile IP 477 +--------+ 478 Figure 5: Home Agent allocated in Visited Realm 480 Upon receipt of a HAA from the Home Agent in the visited realm, with 481 the Result-Code AVP indicating success, the AAAF forwards the HAA to 482 the AAAH in the home realm. The AMA is then constructed, and issued 483 to the AAAF, and finally to the FA. The HAA and AMA MUST include the 484 MIP-Home-Agent-Address and the MIP-Mobile-Node-Address AVPs. 486 Mobile Node Foreign Agent Home Agent AAAF AAAH 487 ----------- ------------- ------------- ---------- ---------- 489 <----Challenge---- 490 Reg-Req (Response)-> 491 ------------AMR-------------> 492 -----AMR----> 493 <----HAR----- 494 <-----HAR------ 495 ------HAA------> 496 -----HAA----> 497 <----AMA----- 498 <-------------AMA------------ 499 <---Reg-Reply---- 500 Figure 6: Mobile IP/Diameter Message Exchange 502 If the Mobile Node moves to another Foreign Network, it MAY either 503 request to keep the same Home Agent within the old foreign network, 504 or request to get a new one in the new foreign network. If the AAAH 505 is willing to provide the requested service, the mobile node will 506 have to interact with two AAAFs. 508 Figure 7 shows the message flows for a Mobile Node requesting to keep 509 the Home Agent assigned in Foreign network 1 when it moves to foreign 510 network 2. Upon reception of the AMR in Foreign network 2, the AAAF 511 follows the procedures described earlier and forwards AMR to the 512 Mobile Node's home network, i.e. its AAAH. If the Mobile Node was 513 successfully authenticated, the AAAH checks the identity of the 514 foreign and home agent to determine whether the user is in a third 515 realm. If this is the case, the AAAH must check whether the mobile is 516 still permitted to use the previously assigned Home Agent. 518 +---------------+ +---------------+ +-------------+ 519 |Foreign net 2 | |Foreign net 1 | |Home network | 520 | | | | | | 521 Mobile Node | FA AAAF | | HA AAAF | | AAAH | 522 ----------- | ---- ---- | | ---- ------ | | ------ | 523 +---------------+ +---------------+ +-------------+ 525 <----Challenge---- 526 Reg-Req (Response)-> 527 ---AMR---> 528 ----------------AMR---------------> 529 <-----HAR----- 530 <---HAR---- 531 ----HAA---> 532 ------HAA----> 533 <---------------AMA---------------- 534 <--AMA---- 535 <----Reg-Reply----- 536 Figure 7: Request to access Home Agent from new Foreign Network 538 If the Mobile Node is allowed to keep the Home Agent the AAAH then 539 sends a HAR, which contains the Mobile IP Registration Request 540 message data encapsulated in the MIP-Reg-Request AVP and the MIP- 541 Home-Agent-Address AVP with Home Agent address, as well as any 542 optional KDC session keys, to the AAAF in foreign network 1. Upon 543 reception the AAAF in foreign network 1 will forward the HAR to the 544 Home Agent if its local policy allows such service. If the AAAF does 545 not permit such service, it MUST return a 546 DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. 548 When the AAAF receives a successful HAA, the AAAF will forward the 549 HAA back to the AAAH. The HAA MUST include the MIP-Home-Agent-Address 550 and the MIP-Mobile-Node-Address AVPs. The AAAH will then send back an 551 AMA to the AAAF in foreign network 2. 553 If the old Foreign Network does not permit the use of its Home Agent 554 when the Mobile Node moves to a new foreign network, the AAAH or AAAF 555 MUST return an AMA with the Result-Code AVP set to 556 DIAMETER_ERROR_HA_NOT_AVAILABLE. Upon receipt of this error, the 557 Foreign Agent MUST issue a Mobile IP Registration Reply to the Mobile 558 Node with an appropriate error. The Mobile Node MAY attempt to 559 request that a new Home Agent and Address be allocated. When the AAAH 560 transmits such an error, it MUST issue a Diameter Abort-Session- 561 Request message to the AAAF overseeing the Home Agent to enable it to 562 release any resources. 564 1.5 Co-located Mobile Node 566 In the event that a Mobile Node registers with the Home Agent as a 567 co-located Mobile Node, there is no Foreign Agent involved. 568 Therefore, when the Home Agent receives the Registration Request, an 569 AMR message is sent to the local AAAH server, with the Co-Located- 570 Mobile-Node bit set in the MIP-Feature-Vector AVP. 572 Home 573 Realm 574 +--------+ 575 | AAAH | 576 | | 577 | server | 578 +--------+ 579 ^ | 580 | | 581 AMR | | AMA 582 | v 583 +--------+ +---------+ 584 | Mobile | Registration | Home | 585 | Node |-------------->| Agent | 586 +--------+ Request +---------+ 587 Figure 8: Co-located Mobile Node 589 If the MN-HA-Key-Requested bit was set in the AMR message from the 590 Home Agent, the Home Agent and Mobile Node's session keys would be 591 present in the AMA message. 593 1.6 Diameter Session Termination 595 A Foreign and Home Agent following this specification MAY expect 596 their respective Diameter servers to maintain session state 597 information for each mobile node in their networks. In order for the 598 Diameter Server to release any resources allocated to a specific 599 mobile node, the mobility agents MUST send a Session-Termination- 600 Request (STR) [1] to their respective Diameter servers. 602 The Home Diameter server SHOULD only deallocate all resources after 603 the STR is received from the Home Agent. This ensures that a Mobile 604 Node that moves from one Foreign Agent to another (hand-off) does not 605 cause the Home Diameter Server to free all resources for the Mobile 606 Node. 608 In the event that the AAAF wishes to terminate a session, its Abort- 609 Session-Request (ASR) [1] message SHOULD be sent to the FA. 610 Similarly, the AAAH SHOULD send its message to the Home Agent. 612 1.7 Advertising application support 614 Diameter nodes conforming to this specification MAY advertise support 615 by including the value of four (4) in the Auth-Application-Id or the 616 Acct-Application-Id AVP of the Capabilities-Exchange-Request and 617 Capabilities-Exchange-Answer command [1]. 619 1.8 Fast Handoff support 621 This application requires that foreign agents issue an AMR upon 622 receipt of the first registration message from a mobile node, 623 regardless of the fact that the mobile node MAY have been previously 624 authorized to another foreign agent. 626 The Mobile IP Working Group is currently investigating fast handoff 627 proposals, and the Seamoby WG is looking at creating a protocol that 628 would allow AAA state information to be exchange between foreign 629 agents during a handoff. These proposals MAY allow future 630 enhancements to the Diameter protocol, in order to reduce the amount 631 of Diameter exchanges required during a handoff. 633 2.0 Command-Code Values 635 This section defines Command-Code [1] values that MUST be supported 636 by all Diameter implementations conforming to this specification. 637 The following Command Codes are defined in this specification: 639 Command-Name Abbreviation Code Section 640 ----------------------------------------------------------- 641 AA-Mobile-Node-Answer AMA 260 2.2 642 AA-Mobile-Node-Request AMR 260 2.1 643 Home-Agent-MIP-Answer HAA 262 2.4 644 Home-Agent-MIP-Request HAR 262 2.3 646 2.1 AA-Mobile-Node-Request 648 The AA-Mobile-Node-Request (AMR), indicated by the Command-Code field 649 set to 260 and the 'R' bit set in the Command Flags field, is sent by 650 an attendant, acting as a Diameter client, to a server in order to 651 request the authentication and authorization of a Mobile Node. The 652 Foreign Agent (or Home Agent in the case of a co-located Mobile Node) 653 uses information found in the Registration Request to construct the 654 following AVPs that are to be included as part of the AMR: 656 home address (MIP-Mobile-Node-Address AVP), 657 home agent address (MIP-Home-Agent-Address AVP), 658 mobile node NAI (User-Name AVP [1]). 659 MN-HA Key Request (MIP-Feature-Vector AVP) 660 MN-FA Key Request (MIP-Feature-Vector AVP) 661 MN-AAA Authentication Extension (MIP-MN-AAA-Auth AVP) 662 Foreign Agent Challenge Extension (MIP-FA-Challenge AVP) 664 If the mobile node's home address is zero, the foreign or home agent 665 MUST NOT include a MIP-Mobile-Node-Address AVP in the AMR. If the 666 home agent address is zero or all ones, the MIP-Home-Agent-Address 667 AVP MUST NOT be present in the AMR. 669 If a Foreign Agent is used in a visited network, the AAAF MAY set the 670 Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP in 671 the AMR message to indicate that it is willing to assign a Home Agent 672 in the visited realm. 674 If the mobile node's home address is all ones, the foreign or home 675 agent MUST include a MIP-Mobile-Node-Address AVP, set to all ones. 677 Message Format 679 ::= < Diameter Header: 260, REQ, PXY > 680 < Session-ID > 681 { Auth-Application-Id } 682 { User-Name } 683 { Destination-Realm } 684 { Origin-Host } 685 { Origin-Realm } 686 { MIP-Reg-Request } 687 { MIP-MN-AAA-Auth } 688 [ Destination-Host ] 689 [ Origin-State-Id ] 690 [ MIP-Mobile-Node-Address ] 691 [ MIP-Home-Agent-Address ] 692 [ MIP-Feature-Vector ] 693 [ Authorization-Lifetime ] 694 [ Auth-Grace-Period ] 695 [ Auth-Session-State ] 696 [ MIP-FA-Challenge ] 697 [ MIP-Candidate-Home-Agent-Host ] 698 * [ AVP ] 699 * [ Proxy-Info ] 700 * [ Route-Record ] 702 2.2 AA-Mobile-Node-Answer 704 The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code field 705 set to 260 and the 'R' bit cleared in the Command Flags field, is 706 sent by the AAAH in response to the AA-Mobile-Node-Request message. 707 The Result-Code AVP MAY contain one of the values defined in section 708 3.0, in addition to the values defined in [1]. 710 An AMA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST 711 include the MIP-Home-Agent-Address, MIP-Home-Mobile-Node-Address and 712 MIP-Reg-Reply AVPs. The MIP-Home-Agent-Address AVP contains the Home 713 Agent assigned to the Mobile Node, while the MIP-Mobile-Node-Address 714 AVP contains the home address that was assigned. The AMA message MUST 715 contain the MIP-FA-to-HA-Key, MIP-FA-to-MN-Key if they were requested 716 in the AMR, and they were present in the HAR. The MIP-MN-to-HA-Key 717 and MIP-HA-to-MN-Key AVPs MUST be present if the session keys were 718 requested in the AMR, and the Co-Located-Mobile-Node bit was set in 719 the MIP-Feature-Vector AVP. 721 An AMA message with the Result-Code AVP set to 722 DIAMETER_LIMITED_SUCCESS MAY include the MIP-Home-Agent-Address AVP 723 if a dynamically assigned home agent was requested by the mobile 724 node. Upon receipt of this result code, the foreign agent MUST issue 725 the Registration Request to the Home Agent in the manner described in 726 [4]. 728 An AMA message with the Result-Code set to DIAMETER_MULTI_ROUND_AUTH 729 MAY include mobile node session key AVPs (see Section 6.1) such as 730 the MIP-MN-to-FA-Key AVP and the MIP-MN-to-HA-Key AVP. If such an AVP 731 is present in the AMA message, the foreign agent MUST include the 732 corresponding Mobile IP key distribution extension in the 733 Registration Reply it sends to the mobile node. This is to support 734 multi-roundtrip authentication mechanisms. 736 Message Format 738 ::= < Diameter Header: 260, PXY > 739 < Session-Id > 740 { Auth-Application-Id } 741 { Result-Code } 742 { Origin-Host } 743 { Origin-Realm } 744 [ Accounting-Multi-Session-Id ] 745 [ Authorization-Lifetime ] 746 [ Auth-Grace-Period ] 747 [ Auth-Session-State ] 748 [ Error-Message ] 749 [ Error-Reporting-Host ] 750 [ Re-Auth-Request-Type ] 751 [ MIP-Reg-Reply ] 752 [ MIP-MN-to-FA-Key ] 753 [ MIP-MN-to-HA-Key ] 754 [ MIP-FA-to-MN-Key ] 755 [ MIP-FA-to-HA-Key ] 756 [ MIP-HA-to-MN-Key ] 757 [ MIP-HA-to-FA-Key ] 758 [ MIP-Key-Lifetime ] 759 [ MIP-Home-Agent-Address ] 760 [ MIP-Mobile-Node-Address ] 761 * [ MIP-Filter-Rule ] 762 [ Session-Timeout ] 763 [ Origin-State-Id ] 764 * [ AVP ] 765 * [ Proxy-Info ] 767 2.3 Home-Agent-MIP-Request 769 The Home-Agent-MIP-Request (HAR), indicated by the Command-Code field 770 set to 262 and the 'R' bit set in the Command Flags field, is sent by 771 the AAA to the Home Agent. If the Home Agent is to be assigned in a 772 foreign network, the HAR is issued by the AAAH and forwarded by the 773 AAAF. If the HAR message does not include a MIP-Mobile-Node-Address 774 AVP, and the Registration Request has 0.0.0.0 for the home address, 775 and the HAR is successfully processed, the Home Agent MUST allocate 776 one such address to the mobile node. If the home agent's local AAA 777 server allocates the mobile node's home address, it MUST include the 778 assigned address in an MIP-Mobile-Node-Address AVP. 780 When session keys are requested for use by the mobile node (see 781 section 5.0), the AAAH MUST create them and include them in the HAR 782 message. When a Foreign-Home session key is requested, it will be 783 created and distributed by the AAA server in the same realm as the 784 home agent. 786 Message Format 788 ::= < Diameter Header: 262, REQ, PXY > 789 < Session-Id > 790 { Auth-Application-Id } 791 { Authorization-Lifetime } 792 { Auth-Grace-Period } 793 { Auth-Session-State } 794 { MIP-Reg-Request } 795 { Origin-Host } 796 { Origin-Realm } 797 { User-Name } 798 { Destination-Realm } 799 { Accounting-Multi-Session-Id } 800 { MIP-Foreign-Agent-Host } 801 { MIP-Feature-Vector } 802 [ Destination-Host ] 803 [ MIP-MN-to-HA-Key ] 804 [ MIP-MN-to-FA-Key ] 805 [ MIP-HA-to-MN-Key ] 806 [ MIP-HA-to-FA-Key ] 807 [ MIP-Key-Lifetime ] 808 [ MIP-Mobile-Node-Address ] 809 [ MIP-Home-Agent-Address ] 810 * [ MIP-Filter-Rule ] 811 [ Session-Timeout ] 812 [ Origin-State-Id ] 813 * [ AVP ] 814 * [ Proxy-Info ] 815 * [ Route-Record ] 817 2.4 Home-Agent-MIP-Answer 819 The Home-Agent-MIP-Answer (HAA), indicated by the Command-Code field 820 set to 262 and the 'R' bit cleared in the Command Flags field, is 821 sent by the Home Agent to its local AAA server in response to a Home- 822 Agent-MIP-Request. If the home agent allocated a home address for the 823 Mobile Node, the address MUST be included in the MIP-Mobile-Node- 824 Address AVP. The Result-Code AVP MAY contain one of the values 825 defined in section 3.0 instead of the values defined in [1]. 827 Message Format 829 ::= < Diameter Header: 262, PXY > 830 < Session-Id > 831 { Auth-Application-Id } 832 { Result-Code } 833 { Origin-Host } 834 { Origin-Realm } 835 { MIP-Foreign-Agent-Host } 836 [ Accounting-Multi-Session-Id ] 837 [ Error-Reporting-Host ] 838 [ Error-Message ] 839 [ MIP-Reg-Reply ] 840 [ MIP-Home-Agent-Address ] 841 [ MIP-Mobile-Node-Address ] 842 [ MIP-FA-to-HA-SPI ] 843 [ MIP-FA-to-MN-SPI ] 844 [ Origin-State-Id ] 845 * [ AVP ] 846 * [ Proxy-Info ] 848 3.0 Result-Code AVP Values 850 This section defines new Result-Code [1] values that MUST be 851 supported by all Diameter implementations that conform to this 852 specification. 854 3.1 Transient Failures 856 Errors that fall within the transient failures category are used to 857 inform a peer that the request could not be satisfied at the time it 858 was received, but MAY be able to satisfy the request in the future. 860 DIAMETER_ERROR_MIP_REPLY_FAILURE 4005 861 This error code is used by the Home Agent when processing of 862 the Registration Request has failed. 864 DIAMETER_ERROR_HA_NOT_AVAILABLE 4006 865 This error code is used to inform the Foreign Agent that the 866 requested Home Agent cannot be assigned to the Mobile Node at 867 this time. The Foreign Agent MUST return a Mobile IP 868 Registration Reply to the Mobile Node with an appropriate error 869 code. 871 DIAMETER_ERROR_BAD_KEY 4007 872 This error code is used by the Home Agent to indicate to the 873 local Diameter server that the key generated is invalid. 875 3.2 Permanent Failures 877 Errors that fall within the permanent failures category are used to 878 inform the peer that the request failed, and should not be attempted 879 again. 881 DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE 5024 882 This error is used by the AAAF to inform the AAAH that 883 allocation of a Home Agent in the Foreign Domain is not 884 permitted at this time. 886 4.0 Mandatory AVPs 888 The following table describes the Diameter AVPs defined in the Mobile 889 IP application, their AVP Code values, types, possible flag values 890 and whether the AVP MAY be encrypted. 892 Due to space constraints, the short form IPFiltrRule is used to 893 represent IPFilterRule and DiamIdent is used to represent 894 DiameterIdentity. 896 +---------------------+ 897 | AVP Flag rules | 898 |----+-----+----+-----|----+ 899 AVP Section | | |SHLD| MUST|MAY | 900 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 901 -----------------------------------------|----+-----+----+-----|----| 902 MIP-Filter-Rule 342 4.9 IPFiltrRule| M | P | | V | Y | 903 MIP-Auth-Input- 338 4.6.2 Unsigned32 | M | P | | V | Y | 904 Data-Length | | | | | | 905 MIP- 339 4.6.3 Unsigned32 | M | P | | V | Y | 906 Authenticator-Length | | | | | | 907 MIP- 340 4.6.4 Unsigned32 | M | P | | V | Y | 908 Authenticator-Offset | | | | | | 909 MIP-Candidate- 336 4.10 DiamIdent | M | P | | V | N | 910 Home-Agent-Host 911 MIP-FA-Challenge 344 4.7 OctetString| M | P | | V | Y | 912 MIP-Feature- 337 4.5 Unsigned32 | M | P | | V | Y | 913 Vector | | | | | | 914 MIP-Foreign- 330 4.8 DiamIdent | M | P | | V | Y | 915 Agent-Host | | | | | | 916 MIP-Home-Agent- 334 4.4 IPAddress | M | P | | V | Y | 917 Address | | | | | | 918 MIP-MN-AAA-Auth 322 4.6 Grouped | M | P | | V | Y | 919 MIP-MN-AAA-SPI 341 4.6.1 Unsigned32 | M | P | | V | Y | 920 MIP-Mobile-Node- 333 4.3 IPAddress | M | P | | V | Y | 921 Address | | | | | | 922 MIP-Reg-Request 320 4.1 OctetString| M | P | | V | Y | 923 MIP-Reg-Reply 321 4.2 OctetString| M | P | | V | Y | 925 4.1 MIP-Reg-Request AVP 927 The MIP-Reg-Request AVP (AVP Code 320) is of type OctetString and 928 contains the Mobile IP Registration Request [4] sent by the Mobile 929 Node to the Foreign Agent. 931 4.2 MIP-Reg-Reply AVP 933 The MIP-Reg-Reply AVP (AVP Code 321) is of type OctetString and 934 contains the Mobile IP Registration Reply [4] sent by the Home Agent 935 to the Foreign Agent. 937 4.3 MIP-Mobile-Node-Address AVP 939 The Mobile-Node-Address AVP (AVP Code 333) is of type IPAddress and 940 contains the Mobile Node's Home Address. 942 4.4 MIP-Home-Agent-Address AVP 944 The Home-Agent-Addess AVP (AVP Code 334) is of type IPAddress and 945 contains the Mobile Node's Home Agent Address. 947 4.5 MIP-Feature-Vector AVP 949 The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and 950 is added with flag values set by the Foreign Agent or by the AAAF 951 owned by the same administrative domain as the Foreign Agent. The 952 Foreign Agent SHOULD include MIP-Feature-Vector AVP within the AMR 953 message it sends to the AAAF. 955 Flag values currently defined include: 956 1 Mobile-Node-Home-Address-Requested 957 2 Home-Address-Allocatable-Only-in-Home-Realm 958 4 Home-Agent-Requested 959 8 Foreign-Home-Agent-Available 960 16 MN-HA-Key-Request 961 32 MN-FA-Key-Request 962 64 FA-HA-Key-Request 963 128 Home-Agent-In-Foreign-Network 964 256 Co-Located-Mobile-Node 966 The flags are set according to the following rules. 968 If the mobile node includes a valid home address (i.e., not equal to 969 0.0.0.0 or 255.255.255.255) in its Registration Request, the Foreign 970 Agent zeroes the Mobile-Node-Home-Address-Requested flag in the MIP- 971 Feature-Vector AVP. 973 If the mobile node sets the home address field equal to 0.0.0.0 in 974 its Registration Request, the Foreign Agent sets the Mobile-Node- 975 Home-Address-Requested flag to one. 977 If the mobile node sets the home agent field equal to 255.255.255.255 978 in its Registration Request, the Foreign Agent sets both the Home- 979 Agent-Requested flag and the Home-Address-Allocatable-Only-in-Home- 980 Realm flag to one in the MIP-Feature-Vector AVP. 982 If the mobile node sets the home agent field equal to 0.0.0.0 in its 983 Registration Request, the Foreign Agent sets the Home-Agent-Requested 984 flag to one, and zeroes the Home-Address-Allocatable-Only-in-Home- 985 Realm flag in the MIP-Feature-Vector AVP. 987 Whenever the Foreign Agent sets either the Mobile-Node-Home-Address- 988 Requested flag or the Home-Agent-Request flag to one, it MUST set the 989 MN-HA-Key-Request flag to one. The MN-HA-Key-Request flag is also set 990 to one if the mobile node includes a Generalized MN-HA Key Request 991 [15] extension, with the subtype set to AAA. 993 If the mobile node includes a Generalized MN-FA Key Request [15] 994 extension with the AAA subtype in its Registration Request, the 995 Foreign Agent sets the MN-FA-Key-Request flag to one in the MIP- 996 Feature-Vector AVP. 998 If the mobile node requests a home agent in the foreign network 999 either by setting the home address field to all ones, or by 1000 specifying a home agent in the foreign network, and the AAAF 1001 authorizes the request, the AAAF MUST set the Home-Agent-In-Foreign- 1002 Network bit to one. 1004 If the Home Agent receives a Registration Request from the Mobile 1005 Node indicating that the MN is acting as a Co-Located Mobile Node, 1006 the Home Agent sets the Co-Located-Mobile-Node bit to one. 1008 If the Foreign Agent's local policy allows it to receive AAA Session 1009 Keys, and it does not have any existing keys with the Home Agent, it 1010 MAY set the FA-HA-Key-Request flag. 1012 The Foreign Agent MUST NOT set the Foreign-Home-Agent-Available, and 1013 Home-Agent-In-Foreign-Network flag to one. 1015 When the AAAF receives the AMR message, it MUST first verify that the 1016 sender was an authorized Foreign Agent. The AAAF then takes any 1017 actions indicated by the settings of the MIP-Feature-Vector AVP 1018 flags. The AAAF then MAY set additional flags.Only the AAAF may set 1019 the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network 1020 flags to one. This is done according to local administrative policy. 1021 When the AAAF has finished setting additional flags according to its 1022 local policy, then the AAAF transmits the AMR with the possibly 1023 modified MIP-Feature-Vector AVP to the AAAH. 1025 4.6 MIP-MN-AAA-Auth AVP 1027 The MN-AAA-Auth AVP (AVP Code 322) is of type Grouped and contains 1028 some ancillary data to simplify processing of the authentication data 1029 in the Mobile IP Registration Request [4] by the target AAA server. 1030 Its value has the following ABNF grammar: 1032 MIP-MN-AAA-Auth ::= < AVP Header: 322 > 1033 { MIP-MN-AAA-SPI } 1034 { MIP-Auth-Input-Data-Length } 1035 { MIP-Authenticator-Length } 1036 { MIP-Authenticator-Offset } 1037 * [ AVP ] 1039 4.6.1 MIP-MN-AAA-SPI AVP 1041 The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and 1042 indicates the algorithm by which the targeted AAA server (AAAH) 1043 should attempt to validate the Authenticator computed by the mobile 1044 node over the Registration Request data. 1046 4.6.2 MIP-Auth-Input-Data-Length AVP 1048 The MIP-Auth-Input-Data-Length AVP (AVP Code 338) is of type 1049 Unsigned32 and contains the length, in bytes, of the Registration 1050 Request data (data portion of MIP-Reg-Request AVP) that should be 1051 used as input to the algorithm (indicated by the MN-AAA-SPI AVP) used 1052 to determine whether the Authenticator Data supplied by the Mobile 1053 Node is valid. 1055 4.6.3 MIP-Authenticator-Length AVP 1057 The MIP-Authenticator-Length AVP (AVP Code 339) is of type Unsigned32 1058 and contains the length of the authenticator to be validated by the 1059 targeted AAA server (i.e., AAAH). 1061 4.6.4 MIP-Authenticator-Offset AVP 1063 The MIP-Authenticator-Offset AVP (AVP Code 340) is of type Unsigned32 1064 and contains the offset into the Registration Request Data, of the 1065 authenticator to be validated by the targeted AAA server (i.e., 1066 AAAH). 1068 4.7 MIP-FA-Challenge 1070 The MIP-FA-Challenge AVP (AVP Code 344) is of type OctetString and 1071 contains the challenge advertised by the Foreign Agent to the Mobile 1072 Node. This AVP MUST be present in the AMR if the Mobile Node used the 1073 RADIUS-style MN-AAA computation algorithm. 1075 4.8 MIP-Foreign-Agent-Host AVP 1077 The MIP-Foreign-Agent-Host AVP (AVP Code 330) is of type 1078 DiameterIdentity and contains the identity of the foreign agent. This 1079 AVP is copied from the value of the Origin-Host AVP in the AMR. 1081 4.9 MIP-Filter-Rule AVP 1083 The MIP-Filter-Rule AVP (AVP Code 342) is of type IPFilterRule, and 1084 provides filter rules that need to be configured on the Foreign or 1085 Home Agent for the user. One or more such AVPs MAY be present in an 1086 authorization response. 1088 4.10 MIP-Candidate-Home-Agent-Host 1090 The MIP-Candidate-Home-Agent-Host AVP (AVP Code 336) is of type 1091 DiameterIdentity and contains the identity of a home agent in the 1092 foreign network that the AAAF proposes be dynamically assigned to the 1093 mobile node. 1095 4.11 MIP-Home-Agent-Host 1097 The MIP-Home-Agent-Host AVP (AVP Code TBD) is of type 1098 DiameterIdentity and contains the identity of the home agent 1099 requested by the mobile node in its registration request. This AVP is 1100 used by the AAAH to determine the destination of the HAR. 1102 5.0 Key Distribution Center 1104 The mobile node and mobility agents use session keys to compute 1105 authentication extensions applied to registration messages, as 1106 defined in [4]: Mobile-Foreign, Foreign-Home and Mobile-Home. If 1107 session keys are requested the AAA server(s) MUST return the key 1108 material after the Mobile Node is successfully authenticated and 1109 authorized. 1111 If the AAAH does not communicate directly with the foreign agent, and 1112 it does not wish for intermediate proxies to have access to the 1113 session keys, they SHOULD be protected using the CMS security 1114 application [9]. 1116 The MIP-Key-Lifetime AVP contains the number of seconds before 1117 session keys destined for the Home Agent and/or Foreign Agent expire. 1118 A value of zero indicates infinity (no timeout). 1120 The SPI values are used as key identifiers, meaning that each session 1121 key has its own SPI value; nodes that share a key also share an SPI. 1123 The Mobile Node proposes SPIs for use in computing the Mobile-Foreign 1124 and Mobile-Home authentication extensions, via the Mobile IP AAA Key 1125 Request extensions [15], while the Home Agent allocates the Mobile- 1126 Foreign, Mobile-Home and Foreign-Home SPIs. 1128 Once the session keys have been distributed, subsequent Mobile IP 1129 registrations need not invoke the AAA infrastructure until the keys 1130 expire. These registrations MUST include the Mobile-Home 1131 authentication extension. In addition, subsequent registrations MUST 1132 also include Mobile-Foreign authentication extension if the Mobile- 1133 Foreign key was generated and distributed by AAA; similarly for 1134 subsequent use of the Foreign-Home authentication extensions. 1136 5.1 Key Material vs. Session Key 1138 Each session key that is generated by the AAAH will generally be 1139 distributed to two parties; for instance, a Mobile-Foreign is sent to 1140 both the mobile node and the foreign agent. 1142 The key sent to the mobile node is always in the form of key 1143 material, which the AAAH does by generating a random [18] value of at 1144 least 64 bits. The random value is used by the mobile node to create 1145 the actual session key. The following is an example of a session 1146 creation procedure, using MD5 as the hashing algorithm. Additional 1147 algorithms are supported, and listed in [15]. 1149 MD5(AAA-Key | key material | node-address | AAA-Key) 1151 Where: 1153 - AAA-Key is the long term secret shared between the mobile 1154 node and the AAAH. 1155 - Key material is a random [18] value of at least 64 bits. 1156 - node-address is the mobile node's identity. This is the 1157 contents of the MIP-Mobile-Node-Address AVP, unless the value 1158 of the AVP is all zero or ones, in which case of value of the 1159 User-Name AVP is used instead. 1161 The AAAH then generates the session key which is destined for the 1162 mobility agent, in this case the foreign agent, by following the 1163 above procedures. It is important that the hashing algorithm used by 1164 the mobile node is the same as the one used by the AAAH in the 1165 session key generation procedure. Therefore, the AAAH MUST know a 1166 priori the transform used, which is typically contained in the mobile 1167 node's configuration profile. The session keys destined for mobility 1168 agents are encoded using the security association available between 1169 the AAA server and the agents (e.g. IPSec, TLS, CMS). 1171 The Foreign-Home session key is shared between two mobility agents: 1172 the FA and HA. Since this key is not destined for the mobile node, 1173 there is no need to follow the session key generation procedures 1174 detailed above. Instead, the AAAH generates a random [18] value of at 1175 least 64 bits for use as the Foreign-Home session key. 1177 See sections 6.0 for details about the format of the AVPs used to 1178 transport the session keys. 1180 5.2 Distributing the Mobile-Home Session Key 1182 If the mobile node does not have a Mobile-Home session key, then the 1183 AAAH is likely to be the only entity trusted that is available to the 1184 mobile node. Thus, the AAAH has to generate the Mobile-Home session 1185 key, and encode it for eventual consumption by the mobile node and 1186 home agent. 1188 If the home agent is in the home realm, then AAAH can directly encode 1189 the Mobile-Home session key into a MIP-HA-to-MN-Key AVP and include 1190 that AVP in the HAR message for delivery to the home agent. 1192 If, on the other hand, the home agent is to be allocated in the 1193 visited realm, the AAAH does not transmit the HAR to the home agent, 1194 but instead transmits the HAR to the AAAF. When the AAAF receives the 1195 HAR, it first allocates a home agent, and then issues the HAR for 1196 that home agent. 1198 The AAAH also has to arrange for the key to be delivered to the 1199 mobile node. Unfortunately, the AAA server only knows about Diameter 1200 messages and AVPs, and the mobile node only knows about Mobile IP 1201 messages and extensions [4]. For this purpose, AAAH encodes the 1202 Mobile-Home session key material into a MIP-MN-to-HA-Key AVP, using 1203 its security association with the mobile node, which is added to the 1204 HAR message, and delivered either to a local home agent, or to the 1205 AAAF in the case where the home agent is in the visited network. The 1206 AAAH has to rely on the home agent (that also understands Diameter) 1207 to transfer the keying information into a Mobile IP Generalized MN-HA 1208 Key Reply extension [15] in the Registration Reply message, using the 1209 SPI proposed by the Mobile Node in the MN-HA Key Request From AAA 1210 Subtype extension. The home agent can format the Reply message and 1211 extensions correctly for eventual delivery to the mobile node. The 1212 resulting Registration Reply is added to the HAA's MIP-Reg-Reply AVP. 1214 After the HAA message is parsed by the AAAH, and transformed into an 1215 AMA, the AMA message containing the MIP-Reg-Reply AVP will eventually 1216 be received by the the foreign agent. The foreign agent can then use 1217 that AVP to recreate a Registration Reply message, containing the 1218 Generalized MN-HA Key Reply extension, for delivery to the mobile 1219 node. 1221 In summary, the AAAH generates the Mobile-Home key material, which is 1222 added to the MIP-MN-to-HA-Key AVP. The key material is then used to 1223 compute the home agent's session key as specified in [15], which is 1224 then added to the MIP-HA-to-MN-Key AVP. These AVPs are delivered to 1225 a home agent by including them in a HAR message sent from either AAAH 1226 or AAAF. The home agent decodes the key for its own use. The home 1227 agent also copies the encoded key material from the MIP-MN-to-HA-Key 1228 AVP into a Generalized MN-HA Key Reply extension appended to the 1229 Mobile IP Registration Reply message. This Registration Reply message 1230 MUST also include the Mobile-Home authentication extension, created 1231 using the newly allocated Mobile-Home session key. The home agent 1232 then encodes the Registration Reply message and extensions into a 1233 MIP-Reg-Reply AVP included as part of the HAA message to be sent back 1234 to the AAA server. 1236 5.3 Distributing the Mobile-Foreign Session Key 1238 The Mobile-Foreign session key material is also generated by AAAH 1239 (upon request) and is added to the MIP-MN-to-FA-Key AVP, which is 1240 added to the HAR, and copied by the home agent into a Generalized MN- 1241 FA Key Reply Extension [15] to the Mobile IP Registration Reply 1242 message, using the SPI proposed by the Mobile Node in the MN-FA Key 1243 Request From AAA Subtype extension. Further, the home agent includes 1244 the SPI in the HAA's MIP-FA-to-MN-SPI AVP. The AAAH includes the 1245 session key in the MIP-FA-to-MN-Key AVP in the HAA, which contains 1246 the session key used by the foreign agent in the computation of the 1247 Mobile-Foreign authentication extension. 1249 Upon receipt of the HAA, the Diameter server responsible for key 1250 allocation creates the MIP-FA-to-HA Key AVP, using the SPI in the 1251 MIP-FA-to-HA-SPI. If the key is generated at the AAAF (home agent in 1252 foreign domain), it adds the MIP-FA-to-HA Key AVP to the HAA and 1253 sends it to the AAAH. Depending upon where the HA was located the 1254 AAAH either generates the MIP-FA-to-HA Key AVP itself or extracts the 1255 AVP from the HAA sent by the AAAF. The AAAH adds the MIP-FA-to-HA Key 1256 to the AMA. If the MIP-FA-to-MN-Key AVP was present in the AMA, the 1257 foreign agent MUST include the Mobile-Foreign authentication 1258 extension in the Registration Reply, using the newly distributed key. 1260 5.4 Distributing the Foreign-Home Session Key 1262 If the home agent is in the home realm, then AAAH has to generate the 1263 Foreign-Home session key. Otherwise, it is generated by AAAF. 1265 In either case, the AAAH includes the session key in the MIP-HA-to- 1266 FA-Key AVP, and includes the AVP as part of the HAR message sent to 1267 the home agent. The corresponding session key that is to be sent to 1268 the foreign agent is cached on the AAAH until the HAA is received. 1270 Upon receipt of the HAR, the home agent recovers the Foreign-Home 1271 session key, allocates an SPI to be used with the key. The allocated 1272 SPI is included in the HAA's MIP-FA-to-HA SPI AVP. 1274 Upon receipt of the HAA, the Diameter server responsible for key 1275 allocation adds the MIP-FA-to-HA Key AVP, using the SPI in the MIP- 1276 FA-to-HA-SPI, and includes the AVP in the AMA. 1278 5.5 Key Distribution Example 1280 Figure 9 provides an example of subsequent Mobile IP message 1281 exchange, assuming that AAAH distributed session keys for all three 1282 MN-FA, FA-HA and HA-MN authentication extensions. 1284 Mobile Node Foreign Agent Home Agent 1285 ----------- ------------- ---------- 1287 Reg-Req(MN-HA-Auth, MN-FA-Auth)--------> 1289 Reg-Req(MN-HA-Auth, FA-HA-Auth)--------> 1291 <--------Reg-Rep(MN-HA-Auth, FA-HA-Auth) 1293 <--------Reg-Rep(MN-HA-Auth, MN-FA-Auth) 1295 Figure 9: Mobile IP Message Exchange 1297 6.0 Key Distribution Center (KDC) AVPs 1299 The Mobile-IP protocol defines a set of security associations shared 1300 between the Mobile Node, Foreign Agent and Home Agents. These three 1301 security associations (Mobile-Home, Mobile-Foreign, and Foreign- 1302 Home), can be dynamically created by the AAAH. This requires that the 1303 AAAH create Mobile-IP Session Keys, and that these keys be 1304 distributed to the three mobile entities, via the Diameter Protocol. 1305 AAA servers supporting the Diameter Mobile IP Application MUST 1306 implement the KDC AVPs defined in this document. In other words, AAA 1307 servers MUST be able to create three session keys: the Mobile-Home, 1308 Mobile-Foreign, and Foreign-Home keys. 1310 The names of the KDC AVPs indicate the two entities sharing the 1311 security association defined by the encrypted key material; the 1312 intended receiver of the AVP is the first named entity. So, for 1313 instance, the MIP-MN-to-HA-Key AVP contains the Mobile-Home key 1314 encrypted in a way that allows it to be recovered by the mobile node. 1316 If strong authentication and confidentiality of the session keys is 1317 required, it is recommended that the CMS security application [9] be 1318 used. 1320 The following table describes the Diameter AVPs defined in the Mobile 1321 IP application, their AVP Code values, types, possible flag values 1322 and whether the AVP MAY be encrypted. 1324 +---------------------+ 1325 | AVP Flag rules | 1326 |----+-----+----+-----|----+ 1327 AVP Section | | |SHLD| MUST|MAY | 1328 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 1329 -----------------------------------------|----+-----+----+-----|----| 1330 MIP-Algorithm- 345 6.8 Enumerated | M | P | | V | Y | 1331 Type | | | | | | 1332 MIP-FA-to-HA-Key 328 6.2 Grouped | M | P | | V | Y | 1333 MIP-FA-to-HA-SPI 318 6.11 Unsigned32 | M | P | | V | Y | 1334 MIP-FA-to-MN-Key 326 6.1 Grouped | M | P | | V | Y | 1335 MIP-FA-to-MN-SPI 319 6.10 Unsigned32 | M | P | | V | Y | 1336 MIP-HA-to-FA-Key 329 6.3 Grouped | M | P | | V | Y | 1337 MIP-HA-to-MN-Key 332 6.4 Grouped | M | P | | V | Y | 1338 MIP-Key-Lifetime 367 6.13 Unsigned32 | M | P | | V | Y | 1339 MIP-Key-Material 335 6.12 OctetString| M | P | | V | Y | 1340 MIP-MN-to-FA-Key 325 6.5 Grouped | M | P | | V | Y | 1341 MIP-MN-to-HA-Key 331 6.6 Grouped | M | P | | V | Y | 1342 MIP-Replay-Mode 346 6.9 Enumerated | M | P | | V | Y | 1343 MIP-Session-Key 343 6.7 OctetString| M | P | | V | Y | 1345 6.1 MIP-FA-to-MN-Key AVP 1347 The MIP-FA-to-MN-Key AVP (AVP Code 326) is of type Grouped, and 1348 contains the Foreign Agent's session key, which it shares with the 1349 Mobile Node. Its Data field has the following ABNF grammar: 1351 MIP-FA-to-MN-Key ::= < AVP Header: 326 > 1352 { MIP-FA-to-MN-SPI } 1353 { MIP-Algorithm-Type } 1354 { MIP-Session-Key } 1355 * [ AVP ] 1357 6.2 MIP-FA-to-HA-Key AVP 1359 The MIP-FA-to-HA-Key AVP (AVP Code 328) is of type Grouped, and 1360 contains the Foreign Agent's session key, which it shares with the 1361 Home Agent. Its Data field has the following ABNF grammar: 1363 MIP-FA-to-HA-Key ::= < AVP Header: 328 > 1364 { MIP-FA-to-HA-SPI } 1365 { MIP-Algorithm-Type } 1366 { MIP-Session-Key } 1367 * [ AVP ] 1369 6.3 MIP-HA-to-FA-Key AVP 1371 The MIP-HA-to-FA-Key AVP (AVP Code 329) is of type Grouped, and 1372 contains the Home Agent's session key, which it shares with the 1373 Foreign Agent. Its Data field has the following ABNF grammar: 1375 MIP-HA-to-FA-Key ::= < AVP Header: 329 > 1376 { MIP-Algorithm-Type } 1377 { MIP-Session-Key } 1378 * [ AVP ] 1380 6.4 MIP-HA-to-MN-Key AVP 1382 The MIP-HA-to-MN-Key AVP (AVP Code 332) is of type Grouped, and 1383 contains the Home Agent's session key, which it shares with the 1384 Mobile Node. Its Data field has the following ABNF grammar: 1386 MIP-HA-to-MN-Key ::= < AVP Header: 332 > 1387 { MIP-Algorithm-Type } 1388 { MIP-Replay-Mode } 1389 { MIP-Session-Key } 1390 * [ AVP ] 1392 6.5 MIP-MN-to-FA-Key AVP 1394 The MIP-MN-to-FA-Key AVP (AVP Code 325) is of type Grouped, and 1395 contains the Mobile Node's key material, which it uses to derive the 1396 session key it shares with the Foreign Agent. The Home Agent uses 1397 this AVP in the construction of the Mobile IP "Unsolicted MN-FA Key 1398 from AAA Subtype" extension [15]. The SPI in the extension's FA SPI 1399 field is allocated by the Home Agent, but it SHOULD take into 1400 consideration the SPI requested by the Mobile Node in the "MN-FA Key 1401 Request From AAA Subtype" extension. 1403 MIP-MN-to-FA-Key ::= < AVP Header: 325 > 1404 { MIP-Algorithm-Type } 1405 { MIP-Key-Material } 1406 { MIP-MN-AAA-SPI } 1407 * [ AVP ] 1409 6.6 MIP-MN-to-HA-Key AVP 1411 The MIP-MN-to-HA-Key AVP (AVP Code 331) is of type Grouped, and 1412 contains the Mobile Node's key material, which it uses to derive the 1413 session key it shares with the Home Agent. The Home Agent uses this 1414 AVP in the construction of the Mobile IP "Unsolicted MN-HA Key from 1415 AAA Subtype" extension [15]. The SPI in the extension's HA SPI field 1416 is allocated by the Home Agent, but it SHOULD take into consideration 1417 the SPI requested by the Mobile Node in the "MN-HA Key Request From 1418 AAA Subtype" extension. 1420 MIP-MN-to-HA-Key ::= < AVP Header: 331 > 1421 { MIP-Algorithm-Type } 1422 { MIP-Replay-Mode } 1423 { MIP-Key-Material } 1424 { MIP-MN-AAA-SPI } 1425 * [ AVP ] 1427 6.7 MIP-Session-Key AVP 1429 The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and 1430 contains the Session Key to be used between two Mobile IP entities. 1432 6.8 MIP-Algorithm-Type AVP 1434 The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated, and 1435 contains the Algorithm identifier used to generate the associated 1436 Mobile IP authentication extension. The following values are 1437 currently defined: 1439 1 Prefix+Suffix MD5 [4] 1440 2 HMAC-MD5 [13] 1441 3 SHA-1 [17] 1443 6.9 MIP-Replay-Mode AVP 1445 The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and 1446 contains the replay mode the Home Agent should use when 1447 authenticating the Mobile Node. 1449 The following values are supported (see [4] for more information): 1451 1 None 1452 2 Timestamps 1453 3 Nonces 1455 6.10 MIP-FA-to-MN-SPI AVP 1457 The MIP-FA-to-MN-SPI AVP (AVP Code 319) is of type Unsigned32, and 1458 contains the Security Parameter Index the Foreign Agent is to use to 1459 refer to the session key it shares with the Mobile Node. The SPI 1460 created MUST NOT be a value between zero (0) and 255, which is the 1461 reserved namespace defined in [4]. This AVP MAY be added in the HAA 1462 message by the Home Agent for the AAAH's use in MIP-FA-to-MN-SPI AVP 1463 of the MIP-FA-to-MN-Key AVP. 1465 6.11 MIP-FA-to-HA-SPI AVP 1467 The MIP-FA-to-HA-SPI AVP (AVP Code 318) is of type Unsigned32, and 1468 contains the Security Parameter Index the Foreign Agent is to use to 1469 refer to the session key it shares with the Home Agent. The SPI 1470 created MUST NOT be a value between zero (0) and 255, which is the 1471 reserved namespace defined in [4]. This AVP MAY be added in the HAA 1472 message by the Home Agent for the AAAH's use in MIP-FA-to-HA-SPI AVP 1473 of the MIP-FA-to-HA-Key AVP. 1475 6.12 MIP-Key-Material AVP 1477 The MIP-Key-Material AVP (AVP Code 335) is of type OctetString and 1478 contains the key material sent to the mobile node. The mobile node 1479 follows the procedures in [15] to generate the session key used to 1480 authenticate Mobile IP registration messages. 1482 6.13 MIP-Key-Lifetime AVP 1484 The MIP-Key-Lifetime AVP (AVP Code 367) is of type Unsigned32 and 1485 represents the period of time (in seconds) for which the session key 1486 is valid. The session key MUST NOT be used if the lifetime has 1487 expired; if the key lifetime expires while the session to which it 1488 applies is still active, either the session key MUST be changed or 1489 the or the session MUST be terminated. 1491 7.0 Accounting AVPs 1493 This section will define the Accounting AVPs that are specific to 1494 Mobile IP, and MUST be included in all Accounting-Request messages. 1495 These AVPs MAY be present in the corresponding Accounting-Answer 1496 messages as well. 1498 7.1 Accounting-Input-Extended-Octets AVP 1500 The Accounting-Input-Extended-Octets AVP (AVP Code 363) is of type 1501 Unsigned64, and contains the number of octets in IP packets received 1502 from the user. 1504 7.2 Accounting-Output-Extended-Octets AVP 1506 The Accounting-Output-Extended-Octets AVP (AVP Code 364) is of type 1507 Unsigned64, and contains the number of octets in IP packets sent to 1508 the user. 1510 7.3 Accounting-Session-Time AVP 1512 The Accounting-Session-Time AVP (AVP Code 46) is of type Unsigned32, 1513 and indicates the length of the current session in seconds. 1515 7.4 Accounting-Input-Extended-Packets AVP 1517 The Accounting-Input-Extended-Packets (AVP Code 365) is of type 1518 Unsigned64, and contains the number of IP packets received from the 1519 user. 1521 7.5 Accounting-Output-Extended-Packets AVP 1523 The Accounting-Output-Extended-Packets (AVP Code 366) is of type 1524 Unsigned64, and contains the number of IP packets sent to the user. 1526 8.0 AVP Occurrence Tables 1528 The following tables presents the AVPs defined in this document, and 1529 specifies in which Diameter messages they MAY, or MAY NOT be present. 1530 Note that AVPs that can only be present within a Grouped AVP are not 1531 represented in this table. 1533 The table uses the following symbols: 1534 0 The AVP MUST NOT be present in the message. 1535 0+ Zero or more instances of the AVP MAY be present in the 1536 message. 1537 0-1 Zero or one instance of the AVP MAY be present in the 1538 message. 1539 1 One instance of the AVP MUST be present in the message. 1541 8.1 Mobile IP Command AVP Table 1543 The table in this section is limited to the Command Codes defined in 1544 this specification. 1546 +-----------------------+ 1547 | Command-Code | 1548 |-----+-----+-----+-----+ 1549 Attribute Name | AMR | AMA | HAR | HAA | 1550 ------------------------------|-----+-----+-----+-----+ 1551 Authorization-Lifetime | 0-1 | 0-1 | 1 | 0 | 1552 Auth-Application-Id | 1 | 1 | 1 | 1 | 1553 Auth-Grace-Period | 0-1 | 0-1 | 1 | 0 | 1554 Auth-Session-State | 0-1 | 0-1 | 1 | 0 | 1555 Destination-Host | 0-1 | 0 | 0-1 | 0 | 1556 Destination-Realm | 1 | 0 | 1 | 0 | 1557 Error-Message | 0 | 0-1 | 0 | 0-1 | 1558 Error-Reporting-Host | 0 | 0-1 | 0 | 0-1 | 1559 MIP-Candidate-Home-Agent-Host | 0-1 | 0 | 0 | 0 | 1560 MIP-FA-Challenge | 0-1 | 0 | 0 | 0 | 1561 MIP-FA-to-HA-Key | 0 | 0-1 | 0-1 | 0 | 1562 MIP-FA-to-HA-SPI | 0 | 0 | 0 | 0-1 | 1563 MIP-FA-to-MN-Key | 0 | 0-1 | 0 | 0 | 1564 MIP-FA-to-MN-SPI | 0 | 0 | 0 | 0-1 | 1565 MIP-Feature-Vector | 0-1 | 0 | 1 | 0 | 1566 MIP-Filter-Rule | 0 | 0+ | 0+ | 0 | 1567 MIP-Foreign-Agent-Host | 0 | 0 | 1 | 1 | 1568 MIP-HA-to-FA-Key | 0 | 0-1 | 0-1 | 0 | 1569 MIP-HA-to-MN-Key | 0 | 0-1 | 0-1 | 0 | 1570 MIP-Home-Agent-Address | 0-1 | 0-1 | 0-1 | 0-1 | 1571 MIP-Key-Lifetime | 0 | 0-1 | 0-1 | 0 | 1572 MIP-MN-AAA-Auth | 1 | 0 | 0 | 0 | 1573 MIP-MN-to-FA-Key | 0 | 0-1 | 0-1 | 0 | 1574 MIP-MN-to-HA-Key | 0 | 0-1 | 0-1 | 0 | 1575 MIP-Mobile-Node-Address | 0-1 | 0-1 | 0-1 | 0-1 | 1576 MIP-Reg-Reply | 0 | 0-1 | 0 | 0-1 | 1577 MIP-Reg-Request | 1 | 0 | 1 | 0 | 1578 Origin-Host | 1 | 1 | 1 | 1 | 1579 Origin-Realm | 1 | 1 | 1 | 1 | 1580 Original-State-Id | 0-1 | 0-1 | 0-1 | 0-1 | 1581 Proxy-Info | 0+ | 0+ | 0+ | 0+ | 1582 Redirect-Host | 0 | 0+ | 0 | 0+ | 1583 Redirect-Host-Usage | 0 | 0-1 | 0 | 0-1 | 1584 Redirect-Max-Cache-Time | 0 | 0-1 | 0 | 0-1 | 1585 Result-Code | 0 | 1 | 0 | 1 | 1586 Re-Auth-Request-Type | 0 | 0-1 | 0 | 0 | 1587 Route-Record | 0+ | 0 | 0+ | 0 | 1588 Session-Id | 1 | 1 | 1 | 1 | 1589 Session-Timeout | 0 | 1 | 1 | 0 | 1590 User-Name | 1 | 0 | 1 | 0 | 1591 ------------------------------|-----+-----+-----+-----| 1593 8.2 Accounting AVP Table 1595 The table in this section is used to represent which AVPs defined in 1596 this document are to be present in the Accounting messages, defined 1597 in [1]. 1599 +-------------+ 1600 | Command-Code| 1601 |------+------+ 1602 Attribute Name | ACR | ACA | 1603 -------------------------------------|------+------+ 1604 Accounting-Input-Extended-Octets | 1 | 0-1 | 1605 Accounting-Input-Extended-Packets | 1 | 0-1 | 1606 Accounting-Output-Extended-Octets | 1 | 0-1 | 1607 Accounting-Output-Extended-Packets | 1 | 0-1 | 1608 Accounting-Session-Time | 1 | 0-1 | 1609 MIP-Feature-Vector | 1 | 0-1 | 1610 MIP-Home-Agent-Address | 1 | 0-1 | 1611 MIP-Mobile-Node-Address | 1 | 0-1 | 1612 -------------------------------------|------+------+ 1614 9.0 Acknowledgements 1616 The following people have contributed text to this document: Fredrik 1617 Johansson, Martin Julien 1619 The authors would like to thank Nenad Trifunovic, Haseeb Akhtar and 1620 Pankaj Patel for their participation in the Document Reading Party, 1621 to Erik Guttman for his very useful proposed text, and to Tony 1622 Johansson for the proposed text AND being in the doc reading party. 1623 The authors would also like to thank the participants of 3GPP2's TSG- 1624 P working group for their valuable feedback. 1626 10.0 IANA Considerations 1628 This section contains the namespaces that have either been created in 1629 this specification, or the values assigned to existing namespaces 1630 managed by IANA. 1632 10.1 Command Codes 1634 This specification assigns the values 260 and 262 from the Command 1635 Code namespace defined in [1]. See section 2.0 for the assignment of 1636 the namespace in this specification. 1638 10.2 AVP Codes 1640 This specification assigns the values 318-346 and 363-367 from the 1641 AVP Code namespace defined in [1]. See sections 4.0 and 6.0 for the 1642 assignment of the namespace in this specification. 1644 10.3 Result-Code AVP Values 1646 This specification assigns the values 4005-4007, and 5024 from the 1647 Result-Code AVP (AVP Code 268) value namespace defined in [1]. See 1648 section 3.0 for the assignment of the namespace in this 1649 specification. 1651 10.4 MIP-Feature-Vector AVP Values 1653 There are 32 bits in the MIP-Feature-Vector AVP (AVP Code 337) that 1654 are available for assignment. This document assigns bits 1-9, as 1655 listed in section 4.5. The remaining bits should only be assigned via 1656 Standards Action [2]. 1658 10.5 MIP-Algorithm-Type AVP Values 1660 As defined in Section 6.8, the MIP-Algorithm-Type AVP (AVP Code 345) 1661 defines the values 1-3. All remaining values are available for 1662 assignment via Designated Expert [2]. 1664 10.6 MIP-Replay-Mode AVP Values 1666 As defined in Section 6.9, the MIP-Replay-Mode AVP (AVP Code 346) 1667 defines the values 1-3. All remaining values, except zero, are 1668 available for assignment via Designated Expert [2]. 1670 10.7 Application Identifier 1672 This specification assigns the value four (4) to the Application 1673 Identifier namespace defined in [1]. See section 1.7 for more 1674 information. 1676 11.0 Security Considerations 1678 This specification describes the Diameter Application necessary to 1679 authenticate and authorize a Mobile IP Mobile Node. The 1680 authentication algorithm used is dependent upon the transforms 1681 available by the Mobile IP protocol, and [5]. This specification also 1682 defines a method by which the home Diameter server can create and 1683 distribute session keys to be used to authenticate Mobile IP 1684 registration messages. The keys SHOULD be be protected using the 1685 methods defined in [9]. 1687 12.0 Acknowledgements 1689 Pat Calhoun would like to thank Sun Microsystems since most of the 1690 effort put into this document was done while he was in their employ. 1692 13.0 References 1694 [1] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens, "Diameter 1695 Base Protocol", draft-ietf-aaa-diameter-08.txt, IETF work in 1696 progress, November 2001. 1698 [2] Narten, Alvestrand,"Guidelines for Writing an IANA Considerations 1699 Section in RFCs", BCP 26, RFC 2434, October 1998 1701 [3] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, Autho- 1702 rization, and Accounting Requirements". RFC 2977. October 2000. 1704 [4] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. 1706 [5] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response Extensions". 1707 RFC 3012. November 2000. 1709 [6] B. Aboba, M. Beadles "The Network Access Identifier." RFC 2486. 1710 January 1999. 1712 [7] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 1713 2477, January 1999. 1715 [8] P. Calhoun, C. Perkins, "Mobile IP Network Address Identifier 1716 Extension", RFC 2794, March 2000. 1718 [9] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security Applica- 1719 tion", draft-ietf-aaa-diameter-cms-sec-03.txt, IETF work in 1720 progress, November 2001. 1722 [10] Kent, Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 1723 2406, November 1998. 1725 [11] S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev- 1726 els", BCP 14, RFC 2119, March 1997. 1728 [12] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 1729 2279, January 1998. 1731 [13] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing for 1732 Message Authentication. RFC 2104, February 1997. 1734 [14] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASREQ Appli- 1735 cation", draft-ietf-aaa-diameter-nasreq-08.txt, IETF work in 1736 progress, November 2001. 1738 [15] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile IP", 1739 draft-ietf-mobileip-aaa-key-08.txt, IETF work in progress, July 1740 2001. 1742 [16] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA", 1743 RFC 3141, June 2001. 1745 [17] National Institute of Standards and Technology, "Secure Hash Stan- 1746 dard", Technical Report NIST FIPS PUB 180-1, U.S. Department of 1747 Commerce, April 1995. 1749 [18] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness Recom- 1750 mendations for Security. Request for Comments (Informational) 1751 1750, Internet Engineering Task Force, December 1994. 1753 14.0 Authors' Addresses 1755 Questions about this memo can be directed to: 1757 Pat R. Calhoun 1758 Black Storm Networks 1759 250 Cambridge Avenue, Suite 200 1760 Palo Alto, California, 94306 1761 USA 1763 Phone: +1 650-617-2932 1764 Fax: +1 650-786-6445 1765 E-mail: pcalhoun@diameter.org 1766 Charles E. Perkins 1767 Nokia Research Center 1768 313 Fairchild Drive 1769 Mountain View, California 94043 1770 USA 1772 Phone: +1 650-625-2986 1773 Fax: +1 650-625-2502 1774 E-Mail: charliep@iprg.nokia.com 1776 15.0 Full Copyright Statement 1778 Copyright (C) The Internet Society (2001). All Rights Reserved. 1780 This document and translations of it may be copied and furnished to 1781 others, and derivative works that comment on or otherwise explain it 1782 or assist in its implementation may be prepared, copied, published 1783 and distributed, in whole or in part, without restriction of any 1784 kind, provided that the above copyright notice and this paragraph are 1785 included on all such copies and derivative works. However, this docu- 1786 ment itself may not be modified in any way, such as by removing the 1787 copyright notice or references to the Internet Society or other 1788 Internet organizations, except as needed for the purpose of develop- 1789 ing Internet standards in which case the procedures for copyrights 1790 defined in the Internet Standards process must be followed, or as 1791 required to translate it into languages other than English. The lim- 1792 ited permissions granted above are perpetual and will not be revoked 1793 by the Internet Society or its successors or assigns. This document 1794 and the information contained herein is provided on an "AS IS" basis 1795 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 1796 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 1797 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1798 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1799 FITNESS FOR A PARTICULAR PURPOSE. 1801 16.0 Expiration Date 1803 This memo is filed as and 1804 expires in May 2002.