idnits 2.17.1 draft-ietf-aaa-diameter-mobileip-04.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 42 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 43 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 19 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 150 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. == 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 (May 2001) is 8382 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) == Missing Reference: '29' is mentioned on line 1122, but not defined == Unused Reference: '10' is defined on line 1847, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1856, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1871, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-04 == Outdated reference: A later version (-08) exists of draft-calhoun-diameter-res-mgmt-06 -- Possible downref: Normative reference to a draft: ref. '2' ** 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') -- 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-04 -- No information found for draft-ietf-aaa-mobileip-aaa-key - is the name correct? -- Possible downref: Normative reference to a draft: ref. '15' == Outdated reference: A later version (-02) exists of draft-hiller-cdma2000-aaa-01 ** Downref: Normative reference to an Informational draft: draft-hiller-cdma2000-aaa (ref. '16') ** Obsolete normative reference: RFC 2434 (ref. '17') (Obsoleted by RFC 5226) Summary: 16 errors (**), 0 flaws (~~), 15 warnings (==), 7 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 Sun Laboratories, Inc. 4 Category: Standards Track Charles E. Perkins 5 Nokia Research Center 6 May 2001 8 Diameter Mobile IPv4 Extensions 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 an extension to the Diameter base protocol 38 that allows a Diameter server to authenticate, authorize and collect 39 accounting information for Mobile IPv4 services rendered to a mobile 40 node. Combined with the Inter-Domain capability of the base 41 protocol, this extension allows mobile nodes to receive service from 42 foreign service providers. Diameter Accounting messages will be used 43 by the Foreign and Home agents to transfer usage information to the 44 Diameter servers. 46 Table of Contents 48 1.0 Introduction 49 1.1 Requirements language 50 1.2 Inter-Domain 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 extension support 56 1.8 Fast Handoff support 57 2.0 Command-Code Values 58 2.1 AA-Mobile-Node-Request (AMR) Command 59 2.2 AA-Mobile-Node-Answer (AMA) Command 60 2.3 Home-Agent-MIP-Request (HAR) Command 61 2.4 Home-Agent-MIP-Answer (HAA) Command 62 3.0 Result-Code AVP Values 63 3.1 Hop-by-Hop Failures 64 4.0 DSI-Event AVP Values 65 5.0 Diameter AVPs 66 5.1 MIP-Reg-Request AVP 67 5.2 MIP-Reg-Reply AVP 68 5.3 MIP-Mobile-Node-Address AVP 69 5.4 MIP-Home-Agent-Address AVP 70 5.5 MIP-Previous-FA-FQDN AVP 71 5.6 MIP-Previous-FA-Addr AVP 72 5.7 MIP-Feature-Vector AVP 73 5.8 MIP-MN-AAA-Auth AVP 74 5.8.1 MIP-MN-AAA-SPI AVP 75 5.8.2 MIP-Auth-Input-Data-Length AVP 76 5.8.3 MIP-Authenticator-Length AVP 77 5.8.4 MIP-Authenticator-Offset AVP 78 5.9 MIP-FA-Challenge AVP 79 5.10 MIP-Foreign-Agent-FQDN AVP 80 6.0 Key Distribution Center 81 6.1 Distributing the Mobile-Home Registration Key 82 6.2 Distributing the Mobile-Foreign Registration Key 83 6.3 Distributing the Foreign-Home Registration Key 84 6.4 Key Distribution Example 85 7.0 Key Distribution Center (KDC) AVPs 86 7.1 Mobile Node Session Keys 87 7.1.1 MIP-MN-to-FA-Key AVP 88 7.1.2 MIP-MN-to-HA-Key AVP 89 7.2 Mobility Agent Session Keys 90 7.2.1 MIP-FA-to-MN-Key AVP 91 7.2.2 MIP-FA-to-HA-Key AVP 92 7.2.3 MIP-HA-to-FA-Key AVP 93 7.2.4 MIP-HA-to-MN-Key AVP 94 7.2.5 MIP-Peer-SPI AVP 95 7.2.6 MIP-Session-Key AVP 96 7.2.7 MIP-Algorithm-Type AVP 97 7.2.8 MIP-Replay-Mode AVP 98 7.3 FA-MN-Preferred-SPI AVP 99 7.4 FA-HA-Preferred-SPI AVP 100 8.0 Accounting AVPs 101 8.1 Accounting-Input-Octets AVP 102 8.2 Accounting-Output-Octets AVP 103 8.3 Accounting-Session-Time AVP 104 8.4 Accounting-Input-Packets AVP 105 8.5 Accounting-Output-Packets AVP 106 9.0 Interactions with Resource Management 107 10.0 AVP Table 108 10.1 Mobile IP Command AVP Table 109 10.2 Accounting AVP Table 110 11.0 Acknowledgements 111 12.0 IANA Considerations 112 12.1 Command Codes 113 12.2 AVP Codes 114 12.3 Result-Code AVP Values 115 12.4 DSI-Event AVP Values 116 12.5 MIP-Feature-Vector AVP Values 117 12.6 MIP-Algorithm-Type AVP Values 118 12.7 MIP-Replay-Mode AVP Values 119 12.8 Extension Identifier 120 13.0 Security Considerations 121 14.0 References 122 15.0 Authors' Addresses 123 16.0 Full Copyright Statement 124 17.0 Expiration Date 126 1.0 Introduction 128 Mobile IP, as defined in [4], defines a method that allows a Mobile 129 Node to change its point of attachment to the Internet with minimal 130 service disruption. Mobile IP does not provide any specific support 131 for mobility across disparate administrative domains, and therefore 132 does not specify how usage can be accounted for, which has limited 133 the applicability of Mobile IP in a IPv4 commercial deployment. The 134 Mobile IP specification as defined in [4] recommends mobile nodes to 135 have a static home address and a home agent. However this may not be 136 always possible in certain deployment scenarios. Recent developments 137 in areas that impact IP mobility in the IETF allow Mobile IP [4] to 138 work just as well when mobile nodes do not have a static home agent 139 and home address. Recent specification [8] allows a mobile node to 140 use its NAI instead of its home address, which better accommodates 141 current administrative practice. 143 This document specifies Extension 4 to the Diameter base protocol [1] 144 that allows a Diameter server to authenticate, authorize and collect 145 accounting information for Mobile IPv4 services rendered to a mobile 146 node. This extension MUST NOT be used in conjunction with the Mobile 147 IPv6 protocol. 149 Combined with the Inter-Domain capability of the base protocol, this 150 extension allows mobile nodes to receive service from foreign 151 service providers. The Diameter Accounting messages will be used by 152 the Foreign and Home agents to transfer usage information to the 153 Diameter servers. 155 The Mobile IP protocol [4] specifies a security model that requires 156 that mobile nodes and home agents share a pre-existing security 157 association, which leads to scaling and configuration issues. This 158 specification defines Diameter functions that allow the AAA server to 159 act as a Key Distribution Center (KDC), whereby dynamic registration 160 keys are created and distributed to the mobility entities for the 161 purposes of securing Mobile IP Registration messages. 163 As with the Diameter base protocol, AAA servers implementing the 164 Mobile IP extension can process users' identities supplied in a 165 Network Access Identifier (NAI) format [6], which is used for 166 Diameter message routing purposes. Mobile nodes include their NAI in 167 Registration messages, as defined in [8]. The use of the NAI is 168 consistent with the roaming model defined by the ROAMOPS Working 169 Group [7]. 171 The Diameter Mobile-IP Extension meets the requirements specified in 172 [3, 16]. Later subsections in this introductory section provide some 173 examples and message flows of the Mobile IP and Diameter messages 174 that occur when a Mobile Node requests service in a foreign network. 175 In this document, the role of the "attendant" [3] is performed by 176 either the home agents (for co-located mobile nodes) or foreign 177 agents for the Mobile-IP Extension, and these terms will be used 178 interchangeably. 180 1.1 Requirements language 182 In this document, the key words "MAY", "MUST", "MUST NOT", 183 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 184 interpreted as described in [11]. 186 1.2 Inter-Domain Mobile IP 188 When a Mobile Node node requests service by issuing a Registration 189 Request to the foreign agent, the foreign agent creates the AA- 190 Mobile-Node-Request (AMR) message, which includes the AVPs defined in 191 section 2.1. The Home Address, Home Agent, Mobile Node NAI and other 192 important fields are extracted from the registration messages for 193 possible inclusion as Diameter AVPs. The AMR message is then 194 forwarded to the local Diameter server, known as the AAA-Foreign, or 195 AAAF. 197 Visited Domain Home Domain 198 +--------+ +--------+ 199 |abc.com | AMR/AMA |xyz.com | 200 | AAAF |<------------------->| AAAH | 201 +->| server | server-server | server | 202 | +--------+ communication +--------+ 203 | ^ ^ 204 | AMR/AMA | client-server | HAR/HAA 205 | | communication | 206 v v v 207 +---------+ +---------+ +---------+ 208 | Foreign | | Foreign | | Home | 209 | Agent | | Agent | | Agent | 210 +---------+ +---------+ +---------+ 211 ^ 212 | Mobile IP 213 | 214 v 215 +--------+ 216 | Mobile | 217 | Node | mn@xyz.com 218 +--------+ 219 Figure 1: Inter-Domain Mobility 221 Upon receiving the AMR, the AAAF follows the procedures outlined in 222 [1] to determine whether the AMR should be processed locally, or if 223 it should be forwarded to another Diameter Server, known as the AAA- 224 Home, or AAAH. Figure 1 shows an example in which a mobile node 225 (mn@xyz.com) requests service from a foreign provider (abc.com). The 226 request received by the AAAF is forwarded to xyz.com's AAAH server. 228 Figure 2 shows the message flows involved when the foreign agent 229 invokes the AAA infrastructure to request that a mobile node be 230 authenticated and authorized. Note that it is not required that the 231 foreign agent invoke AAA services every time a Registration Request 232 is received from the mobile, but rather only when the prior 233 authorization from the AAAH expires. The expiration time of the 234 authorization (and registration keys, if allocated by the AAA server) 235 is communicated through the Authorization-Lifetime AVP in the AA- 236 Mobile-Node-Answer (AMA, see section 2.2) from the AAAH. 238 Mobile Node Foreign Agent AAAF AAAH Home Agent 239 ----------- ------------- ------------ ---------- ---------- 240 Advertisement & 241 <--------- Challenge 243 Reg-Req&MN-AAA ----> 245 AMR------------> 246 Session-Id = foo 248 AMR------------> 249 Session-Id = foo 251 HAR-----------> 252 Session-Id = bar 254 <----------HAA 255 Session-Id = bar 257 <-----------AMA 258 Session-Id = foo 260 <------------AMA 261 Session-Id = foo 263 <-------Reg-Reply 265 Figure 2: Mobile IP/Diameter Message Exchange 267 The foreign agent (as shown in Figure 2) MAY provide a challenge, 268 which gives it direct control over the replay protection in the 269 Mobile IP registration process, as described in [5]. The mobile node 270 includes the Challenge and MN-AAA authentication extension to enable 271 authorization by AAAH. If the authentication data supplied in the 272 MN-AAA extension is invalid, AAAH returns the response (AMA) with the 273 Result-Code AVP set to DIAMETER_ERROR_AUTH_FAILURE (see section 3.0). 275 In the event that the AMR generated by the FA is for a session that 276 has was previously authorized by the AAAH, it MUST include the 277 Destination-FQDN AVP, with the identity of the AAAH. The AAAH's 278 identity can be retrieved from the Origin-FQDN AVP in the last AMA 279 received for the session. 281 If the Mobile Node was successfully authenticated, the AAAH checks if 282 the Home Agent was located in the foreign domain, by checking the 283 Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. If 284 the flag is enabled, then the Home Agent is located in the foreign 285 domain then AAAH sends an HAR message to AAAF which contains a MIP- 286 Reg-Request AVP. 288 If the Home Agent was not located in the foreign domain, the AAAH 289 checks for the MIP-Home-Agent-Address AVP. If one was specified, the 290 AAAH checks that the address is that of a known Home Agent, and one 291 that the Mobile Node is allowed to request, and the Home Agent's 292 identity is included in the Destination-FQDN AVP. If no Home Agent 293 was specified, and if the MIP-Feature-Vector has the Home-Agent- 294 Requested flag set, and if allowed by policy in the home domain, the 295 AAAH SHOULD allocate a home agent on behalf of the Mobile Node. This 296 can be done in a variety of ways, including using a load balancing 297 algorithm in order to keep the load on all home agents equal. The 298 actual algorithm used and the method of discovering the home agents 299 is outside the scope of this specification. 301 The AAAH then sends an Home-Agent-MIP-Request (HAR), which contains 302 the Mobile IP Registration Request message data encapsulated in the 303 MIP-Reg-Request AVP, to the assigned or requested Home Agent. The 304 AAAH MAY allocate a home address for the mobile node, and include it 305 in a MIP-Mobile-Node-Address AVP within the HAR, or else leave this 306 allocation responsibility for the Home Agent. 308 For new sessions, the AAAH MUST create an accounting session 309 identifier, which is added to the Acct-Session-Id AVP in the HAR 310 message sent to the home agent. 312 During the creation of the HAR, the AAAH MUST use a different session 313 identifier than the one used in the AMR/AMA (see figure 2). Of 314 course, the AAAH MUST use the same session identifier for all HARs 315 initiated on behalf of a given mobile node's session. A mobile node's 316 session is identified via its identity in the User-Name AVP, the 317 MIP-Mobile-Node-Address and MIP-Home-Agent-Address AVPs. This is 318 necessary in order to allow the session state machine, defined in the 319 base protocol [1], to be used unmodified with this extension. 320 Therefore, an STR from a foreign agent would free the session from 321 the foreign agent, but not the one towards the home agent (see figure 322 3). 324 STR, Session-Id = foo STR, Session-Id = bar 325 ---------------------> <-------------------- 326 +----+ +------+ +------+ +----+ 327 | FA | | AAAF | | AAAH | | HA | 328 +----+ +------+ +------+ +----+ 329 <--------------------- ---------------------> 330 STA, Session-Id = foo STA, Session-Id = bar 331 Figure 3: Session Termination and Session Identifiers 333 Upon receipt of the HAR, the Home Agent first processes the Diameter 334 message. The Home Agent processes the MIP-Reg-Request AVP and creates 335 the Registration Reply, encapsulating it within the MIP-Reg-Reply 336 AVP. If a home address is needed, the Home Agent MUST assign one and 337 include the address in both the Registration Reply and within the 338 MIP-Mobile-Node-Address AVP. The Acct-Session-Id AVP in the HAR MUST 339 be included in the HAA, which is then forwarded to the AAAH. 341 Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer 342 (AMA) message, includes the Acct-Session-Id that was present in the 343 HAA, and the MIP-Home-Agent-Address, MIP-Mobile-Node-Address AVPs in 344 the AMA message, enabling appropriate firewall controls for the 345 penetration of tunneled traffic between the Home Agent and the Mobile 346 Node. 348 The AAAF is responsible for ensuring that the AMA message is properly 349 forwarded to the correct foreign agent. 351 1.3 Support for Mobile IP Handoffs 353 Given the nature of Mobile IP, a mobile node MAY receive service from 354 many foreign agents during a period of time. However, the Home Domain 355 should not view these handoffs as different sessions, since this 356 could affect billing systems. Furthermore, many foreign agents do not 357 communicate, which makes it quite difficult for AAA information to be 358 exchanged between these entities. Therefore, it MUST be assumed that 359 a foreign agent is not aware that a registration request from a 360 mobile node has been previously authorized. 362 The first registration request from a mobile node will therefore 363 cause an AMR to be sent to its AAAF. The AMR will include a new 364 session identifier, and MAY even be sent to a different AAAF in the 365 visited network. It is also quite likely that the AMR will be 366 received by a different AAAH. 368 Since the new AAAH in the home network MAY not have access to the 369 session identifier that was used by the old AAAH, it is necessary for 370 the resulting HAR received by the HA to be identified as a 371 continuation of an existing session. If the HA receives an HAR for a 372 mobile node, with a new session identifier, and the HA can guarantee 373 that this request is to extend service for an existing service, then 374 the HA MUST be able to modify its internal session state information 375 to reflect the new AAAH and session identifier. The HA MUST also 376 issue an STR message with the old session identifier to the AAAH it 377 was communicating with when using the old session identifier. 379 It is necessary for accounting records to have some commonality 380 across handoffs in order for correlation to occur. Therefore, in the 381 event that a home agent receives an HAR with a different Acct- 382 Session-id AVP (and obviously a different Session-Id AVP), the home 383 agent MUST send an HAA with the Acct-Session-Id AVP that was received 384 by the AAAH in the first HAR for the mobile's session. This modified 385 Acct-Session-Id AVP will be returned to the foreign agent by the AAAH 386 in the AMA. Both the foreign and home agents MUST include the Acct- 387 Session-Id in the accounting messages. 389 ACR, Session-Id = foo ACR, Session-Id = bar 390 Acct-Session-Id = a Acct-Session-Id = a 391 ---------------------> <-------------------- 392 +----+ +------+ +------+ +----+ 393 | FA | | AAAF | | AAAH | | HA | 394 +----+ +------+ +------+ +----+ 395 <--------------------- ---------------------> 396 ACA, Session-Id = foo ACA, Session-Id = bar 398 Figure 4: Accounting messages w/ Mobile IP extension 400 1.4 Allocation of Home Agent in Foreign Network 402 The Diameter Mobile IP extension allows a Home Agent to be allocated 403 in a foreign network, as required in [3, 16]. When a foreign agent 404 detects that the mobile node has a home agent address equal to 405 0.0.0.0 or 255.255.255.255 in the Registration Request message, it 406 MUST add a MIP-Feature-Vector AVP with the Home-Agent-Requested flag 407 set to one. If the home agent address is equal to 255.255.255.255, 408 then the foreign agent also MUST set the Home-Address-Allocatable- 409 Only-in-Home-Domain flag equal to one. If the home agent address is 410 set to 0.0.0.0, the foreign agent MUST set the Home-Address- 411 Allocatable-Only-in-Home-Domain flag equal to zero. 413 When the AAAF receives a AMR message with the Home-Agent-Requested 414 flag set to one, and the Home-Address-Allocatable-Only-in-Home-Domain 415 flag equal to zero, AAAF MAY set the Foreign-Home-Agent-Available 416 flag in the MIP-Feature-Vector AVP to inform the AAAH that it is 417 willing and able to assign a Home Agent for the Mobile Node. 419 In the event that the mobile node requests a home agent in the 420 foreign network, and the AAAF authorizes its use, the AAAF MUST set 421 the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. 422 This could happen when the AAA request is sent to "extend" a mobile 423 node's current session. 425 When the AAAH receives a AMR message, it first checks the 426 authentication data supplied by the mobile node, according to the 427 MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether 428 to authorize the mobile node. If the AMR indicates that the AAAF has 429 offered to allocate a home agent for the mobile node, then the AAAH 430 must decide whether its local policy would allow the user to have a 431 Home Agent in the foreign network. If so, and after checking 432 authorization from the data in the AMR message, the AAAH sends the 433 HAR message to the AAAF that does not contain the MIP-Home-Agent- 434 Address. The AAAF MUST allocate a Home Agent, if one has not already 435 been assigned to the Mobile Node, and the AAAF forwards the HAR 436 message to the Home Agent. 438 Visited Home 439 Domain Domain 440 +--------+ ------- AMR -------> +--------+ 441 | AAAF | <------ HAR -------- | AAAH | 442 | | | | 443 +--->| server | ------- HAA -------> | server | 444 | +--------+ <------ AMA -------- +--------+ 445 | ^ | 446 | | | 447 HAR/HAA | AMR | | AMA 448 v | v 449 +---------+ +---------+ 450 | Home | | Foreign | 451 | Agent | | Agent | 452 +---------+ +---------+ 453 ^ 454 +--------+ | 455 | Mobile |<----------+ 456 | Node | Mobile IP 457 +--------+ 458 Figure 5: Home Agent allocated in Visited Domain 460 Upon receipt of a HAA from the Home Agent in the Visited Domain, with 461 the Result-Code AVP indicating success, the AAAF forwards the HAA to 462 the AAAH in the home domain. The AMA is then constructed, and issued 463 to the AAAF, and finally to the FA. The HAA and AMA MUST include the 464 MIP-Home-Agent-Address and the MIP-Mobile-Node-Address AVPs. 466 Mobile Node Foreign Agent Home Agent AAAF AAAH 467 ----------- ------------- ------------- ---------- ---------- 469 <----Challenge---- 470 Reg-Req (Response)-> 471 ------------AMR-------------> 472 -----AMR----> 473 <----HAR----- 474 <-----HAR------ 475 ------HAA------> 476 -----HAA----> 477 <----AMA----- 478 <-------------AMA------------ 479 <---Reg-Reply---- 480 Figure 6: Mobile IP/Diameter Message Exchange 482 If the Mobile Node moves to another Foreign Network, it MAY either 483 request to keep the same Home Agent within the old foreign network, 484 or request to get a new one in the new foreign network. If the AAAH 485 is willing to provide the requested service, the mobile node will 486 have to interact with two AAAFs. 488 Figure 7 shows the message flows for a Mobile Node requesting to keep 489 the Home Agent assigned in Foreign network 1 when it moves to foreign 490 network 2. Upon reception of the AMR in Foreign network 2, the AAAF 491 follows the procedures described earlier and forwards AMR to the 492 Mobile Node's home network, i.e. its AAAH. If the Mobile Node was 493 successfully authenticated the AAAH checks for the Origin-FQDN and 494 the MIP-Previous-FA-FQDN AVPs. If a AAAH deduces that the Mobile Node 495 has moved to a new domain, it must check whether the Mobile can still 496 use the previously assigned Home Agent. 498 +---------------+ +---------------+ +-------------+ 499 |Foreign net 2 | |Foreign net 1 | |Home network | 500 | | | | | | 501 Mobile Node | FA AAAF | | HA AAAF | | AAAH | 502 ----------- | ---- ---- | | ---- ------ | | ------ | 503 +---------------+ +---------------+ +-------------+ 505 <----Challenge---- 506 Reg-Req (Response)-> 507 ---AMR---> 508 ----------------AMR---------------> 509 <-----HAR----- 510 <---HAR---- 511 ----HAA---> 512 ------HAA----> 513 <---------------AMA---------------- 514 <--AMA---- 515 <----Reg-Reply----- 516 Figure 7: Request to access Home Agent from new Foreign Network 518 If the Mobile Node is allowed to keep the Home Agent the AAAH then 519 sends a HAR, which contains the Mobile IP Registration Request 520 message data encapsulated in the MIP-Reg-Request AVP and the MIP- 521 Home-Agent-Address AVP with Home Agent address, as well as any 522 optional KDC session keys, to the AAAF in foreign network 1. Upon 523 reception the AAAF in foreign network 1 will forward the HAR to the 524 Home Agent if its local policy allows such service. If the AAAF does 525 not permit such service, it MUST return a 526 DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. 528 When the AAAF receives a successful HAA, the AAAF will forward the 529 HAA back to the AAAH. The HAA MUST include the MIP-Home-Agent-Address 530 and the MIP-Mobile-Node-Address AVPs. The AAAH will then send back an 531 AMA to the AAAF in foreign network 2. 533 If the old Foreign Network does not permit the use of its Home Agent 534 when the Mobile Node moves to a new foreign network, the AAAH or AAAF 535 MUST return an AMA with the Result-Code AVP set to 536 DIAMETER_ERROR_HA_NOT_AVAILABLE. Upon receipt of this error, the 537 Foreign Agent MUST issue a Mobile IP Registration Reply to the Mobile 538 Node with an appropriate error. The Mobile Node MAY attempt to 539 request that a new Home Agent and Address be allocated. When the AAAH 540 transmits such an error, it MUST issue a Diameter Session- 541 Termination-Indication message to the AAAF overseeing the Home Agent 542 to enable it to release any resources. 544 1.5 Co-located Mobile Node 545 In the event that a Mobile Node registers with the Home Agent as a 546 co-located Mobile Node, there is no Foreign Agent involved. 547 Therefore, when the Home Agent receives the Registration Request, an 548 AMR message is sent to the local AAAH server, with the Co-Located- 549 Mobile-Node bit set in the MIP-Feature-Vector AVP. 551 Home 552 Domain 553 +--------+ 554 | AAAH | 555 | | 556 | server | 557 +--------+ 558 ^ | 559 | | 560 AMR | | AMA 561 | v 562 +--------+ +---------+ 563 | Mobile | Registration | Home | 564 | Node |-------------->| Agent | 565 +--------+ Request +---------+ 566 Figure 8: Co-located Mobile Node 568 If the MN-HA-Key-Requested bit was set in the AMR message from 569 the Home Agent, the Home Agent and Mobile Node's session keys 570 would be present in the AMA message. 572 1.6 Diameter Session Termination 574 A Foreign and Home Agent following this specification MAY expect 575 their respective Diameter servers to maintain session state 576 information for each mobile node in their networks. In order for the 577 Diameter Server to release any resources allocated to a specific 578 mobile node, the mobility agents MUST send a Session-Termination- 579 Request (STR) [1] to their respective Diameter servers. 581 The Home Diameter server SHOULD only deallocate all resources after 582 the STR is received from the Home Agent. This ensures that a Mobile 583 Node that moves from one Foreign Agent to another (hand-off) does not 584 cause the Home Diameter Server to free all resources for the Mobile 585 Node. 587 In the event that the AAAF wishes to terminate a session, its 588 Session-Termination-Ind (STI) [1] message SHOULD be sent to the FA. 589 Similarly, the AAAH SHOULD send its message to the Home Agent. 591 1.7 Advertising extension support 593 Diameter nodes conforming to this specification MAY advertise support 594 by including the value of four (4) in either the Device-Reboot-Ind 595 Command's [1] Auth-Extension-Id or Acct-Extension-Id AVPs. 597 1.8 Fast Handoff support 599 This extension requires that foreign agents issue an AMR upon receipt 600 of the first registration message from a mobile node, regardless of 601 the fact that the mobile node MAY have been previously authorized to 602 another foreign agent. 604 The Mobile IP Working Group is currently investigating fast handoff 605 proposals, and the Seamoby WG is looking at creating a protocol that 606 would allow AAA state information to be exchange between foreign 607 agents during a handoff. These proposals MAY allow future 608 enhancements to the Diameter protocol, in order to reduce the amount 609 of Diameter exchanges required during a handoff. 611 2.0 Command-Code Values 613 This section defines Command-Code [1] values that MUST be supported 614 by all Diameter implementations conforming to this specification. 615 The following Command Codes are defined in this specification: 617 Command-Name Abbreviation Code Section 618 ----------------------------------------------------------- 619 AA-Mobile-Node-Answer AMA 260 2.2 620 AA-Mobile-Node-Request AMR 260 2.1 621 Home-Agent-MIP-Answer HAA 262 2.4 622 Home-Agent-MIP-Request HAR 262 2.3 624 2.1 AA-Mobile-Node-Request (AMR) Command 626 The AA-Mobile-Node-Request (AMR), indicated by the Command-Code field 627 set to 260 and the 'R' bit set in the message flags field, is sent by 628 an attendant, acting as a Diameter client, to a server in order to 629 request the authentication and authorization of a Mobile Node. The 630 Foreign Agent (or Home Agent in the case of a co-located Mobile Node) 631 uses information found in the Registration Request to construct the 632 following AVPs that are to be included as part of the AMR: 634 home address (MIP-Mobile-Node-Address AVP), 635 home agent address (MIP-Home-Agent-Address AVP), 636 mobile node NAI (User-Name AVP [1]). 637 MN-HA Key Request (MIP-Feature-Vector AVP) 638 MN-FA Key Request (MIP-Feature-Vector AVP) 639 MN-AAA Authentication Extension 640 Foreign Agent Challenge Extension 642 If the mobile node's home address is zero, the foreign or home agent 643 MUST NOT include a MIP-Mobile-Node-Address AVP in the AMR. If the 644 home agent address is zero or all ones, the MIP-Home-Agent-Address 645 AVP MUST NOT be present in the AMR. 647 If a Foreign Agent is used in a visited network, the AAAF MAY set the 648 Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP in 649 the AMR message to indicate that it is willing to assign a Home Agent 650 in the visited domain. 652 If the MIP-Previous-FA-FQDN AVP is found in the request, the Diameter 653 client requests that the server return the registration key that was 654 assigned to the previous Foreign Agent for use with the Mobile Node 655 and Home Agent. The registration key is identified through the use of 656 the User-Name AVP. 658 Message Format 660 ::= < Diameter Header: 260, R > 661 < Session-ID > 662 { Auth-Extension-Id } 663 { User-Name } 664 { Destination-Realm } 665 { Origin-FQDN } 666 { Origin-Realm } 667 { MIP-Reg-Request } 668 { MIP-MN-AAA-Auth } 669 [ MIP-Mobile-Node-Address ] 670 [ MIP-Home-Agent-Address ] 671 [ MIP-Feature-Vector ] 672 [ Authorization-Lifetime ] 673 [ MIP-FA-MN-Preferred-SPI ] 674 [ MIP-FA-HA-Preferred-SPI ] 675 [ MIP-Previous-FA-FQDN ] 676 [ MIP-Previous-FA-Addr ] 677 [ MIP-FA-Challenge ] 678 [ Destination-FQDN ] 679 * [ AVP ] 680 * [ Proxy-Info ] 681 * [ Route-Record ] 683 2.2 AA-Mobile-Node-Answer (AMA) Command 685 The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code field 686 set to 261 and the 'A' bit set in the message flags field, is sent by 687 the AAAH in response to the AA-Mobile-Node-Request message. The 688 Result-Code AVP MAY contain one of the values defined in section 3.0, 689 in addition to the values defined in [1]. 691 A successful AMA message MUST include the MIP-Home-Agent-Address, 692 MIP-Home-Mobile-Node-Address AVP and MIP-Reg-Reply AVPs. The MIP- 693 Home-Agent-Address AVP contains the Home Agent assigned to the Mobile 694 Node, while the MIP-Mobile-Node-Address AVP contains the home address 695 that was assigned. 697 The AMA message MUST contain the MIP-FA-to-HA-Key, MIP-FA-to-MN-Key 698 if they were requested in the AMR, and they were present in the HAR. 700 The MIP-MN-to-HA-Key and MIP-HA-to-MN-Key AVPs MUST be present if the 701 session keys were requested in the AMR, and the Co-Located-Mobile- 702 Node bit was set in the MIP-Feature-Vector AVP. 704 Message Format 706 ::= < Diameter Header: 260, A > 707 < Session-Id > 708 { Auth-Extension-Id } 709 { Authorization-Lifetime } 710 { Result-Code } 711 { Origin-FQDN } 712 { Origin-Realm } 713 { Destination-FQDN } 714 { Acct-Session-Id } 715 [ Error-Reporting-FQDN ] 716 [ MIP-Reg-Reply ] 717 [ MIP-MN-to-HA-Key ] 718 [ MIP-FA-to-MN-Key ] 719 [ MIP-FA-to-HA-Key ] 720 [ MIP-HA-to-MN-Key ] 721 [ MIP-Home-Agent-Address ] 722 [ MIP-Mobile-Node-Address ] 723 * [ Filter-Rule ] 724 [ Session-Timeout ] 725 * [ AVP ] 726 * [ Proxy-Info ] 727 * [ Route-Record ] 729 2.3 Home-Agent-MIP-Request (HAR) Command 730 The Home-Agent-MIP-Request (HAR), indicated by the Command-Code field 731 set to 262 and the 'R' bit set in the message flags field, is sent by 732 the AAA to the Home Agent. If the Home Agent is to be assigned in a 733 foreign network, the HAR is issued by the AAAH and forwarded by the 734 AAAF. If the HAR message does not include a MIP-Mobile-Node-Address 735 AVP, and the Registration Request has 0.0.0.0 for the home address, 736 and the HAR is successfully processed, the Home Agent MUST allocate 737 one such address to the mobile node. If the home agent's local AAA 738 server allocates the mobile node's home address, it MUST include the 739 assigned address in an MIP-Mobile-Node-Address AVP. 741 When registration keys are requested for use by the mobile node (see 742 section 6.0), the AAAH MUST create them and include them in the HAR 743 message. When a Foreign-Home registration key is requested, it will 744 be created and distributed by the AAA server in the same domain as 745 the home agent. 747 Message Format 749 ::= < Diameter Header: 262, R > 750 < Session-Id > 751 { Auth-Extension-Id } 752 { Authorization-Lifetime } 753 { MIP-Reg-Request } 754 { Origin-FQDN } 755 { Origin-Realm } 756 { User-Name } 757 { Destination-Realm } 758 { Acct-Session-Id } 759 { MIP-Foreign-Agent-FQDN } 760 [ Destination-FQDN ] 761 [ MIP-MN-to-HA-Key ] 762 [ MIP-MN-to-FA-Key ] 763 [ MIP-HA-to-MN-Key ] 764 [ MIP-HA-to-FA-Key ] 765 [ MIP-FA-to-MN-Key ] 766 [ MIP-FA-to-HA-Key ] 767 [ MIP-Mobile-Node-Address ] 768 [ MIP-Home-Agent-Address ] 769 * [ Filter-Rule ] 770 [ Session-Timeout ] 771 * [ AVP ] 772 * [ Proxy-Info ] 773 * [ Route-Record ] 775 2.4 Home-Agent-MIP-Answer (HAA) Command 776 The Home-Agent-MIP-Answer (HAA), indicated by the Command-Code field 777 set to 262 and the 'A' bit set in the message flags field, is sent by 778 the Home Agent to its local AAA server in response to a Home-Agent- 779 MIP-Request. If the home agent allocated a home address for the 780 Mobile Node, the address MUST be included in the MIP-Mobile-Node- 781 Address AVP. The Result-Code AVP MAY contain one of the values 782 defined in section 3.0 instead of the values defined in [1]. 784 Message Format 786 ::= < Diameter Header: 262, A > 787 < Session-Id > 788 { Auth-Extension-Id } 789 { Session-Timeout } 790 { Authorization-Lifetime } 791 { Result-Code } 792 { Origin-FQDN } 793 { Origin-Realm } 794 { Destination-FQDN } 795 { Acct-Session-Id } 796 { MIP-Foreign-Agent-FQDN } 797 [ Error-Reporting-FQDN ] 798 [ MIP-Reg-Reply ] 799 [ MIP-Home-Agent-Address ] 800 [ MIP-Mobile-Node-Address ] 801 [ MIP-FA-to-MN-Key ] 802 [ MIP-FA-to-HA-Key ] 803 [ Filter-Rule ] 804 * [ AVP ] 805 * [ Proxy-Info ] 806 * [ Route-Record ] 808 3.0 Result-Code AVP Values 810 This section defines new Result-Code [1] values that MUST be 811 supported by all Diameter implementations that conform to this 812 specification. 814 3.1 Transient Failures 816 Errors that fall within the transient failures category are used to 817 inform a peer that the request could not be satisfied at the time it 818 was received, but MAY be able to satisfy the request in the future. 820 DIAMETER_ERROR_AUTH_FAILURE 4004 821 This error code is used by AAAH to inform the attendant that 822 the authentication data in the MN-AAA authentication extension 823 is invalid. 825 DIAMETER_ERROR_MIP_REPLY_FAILURE 4005 826 This error code is used by the Home Agent when processing of 827 the Registration Request has failed. 829 DIAMETER_ERROR_HA_NOT_AVAILABLE 4006 830 This error code is used to inform the Foreign Agent that the 831 requested Home Agent cannot be assigned to the Mobile Node at 832 this time. The Foreign Agent MUST return a Mobile IP 833 Registration Reply to the Mobile Node with an appropriate error 834 code. 836 4.0 DSI-Event Values 838 This section defines new DSI-Event [1] values that MUST be supported 839 by all Diameter implementations that conform to this specification. 841 4.1 Transient Failure Events 843 Errors that fall within the transient failures category are used to 844 inform a peer that the request could not be satisfied at the time it 845 was received, but MAY be able to satisfy the request if the error is 846 corrected. 848 DIAMETER_ERROR_BAD_KEY 4002 849 This error code is used by the Home Agent to indicate to the 850 local Diameter server that the key generated is invalid. 852 DIAMETER_ERROR_BAD_HOME_ADDRESS 4003 853 This error code is used by the Home Agent to indicate that the 854 Home Address chosen by the Mobile Node or assigned by the local 855 Diameter server is unavailable. 857 4.2 Permanent Failure Events 859 Errors that fall within the permanent failures category are used to 860 inform the peer that the request failed, and cannot be satisfied by 861 the originator of the Device-Status-Ind. The receiver of a DSI 862 message with the DSI-Event set to a value that falls within this 863 event class SHOULD forward the message to an alternate peer, if one 864 is available. 866 DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE 5009 867 This error is used by the AAAF to inform the AAAH that 868 allocation of a Home Agent in the Foreign Agent is not 869 permitted at this time. 871 5.0 Mandatory AVPs 873 The following table describes the Diameter AVPs defined in the Mobile 874 IP extension, their AVP Code values, types, possible flag values and 875 whether the AVP MAY be encrypted. 877 +---------------------+ 878 | AVP Flag rules | 879 |----+-----+----+-----|----+ 880 AVP Section | | |SHLD| MUST|MAY | 881 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 882 -----------------------------------------|----+-----+----+-----|----| 883 Filter-Rule 400 5.10 OctetString| M | P | | V | Y | 884 MIP-Auth-Input- 338 5.8.2 Unsigned32 | M | P | | V | Y | 885 Data-Length | | | | | | 886 MIP- 339 5.8.3 Unsigned32 | M | P | | V | Y | 887 Authenticator-Length | | | | | | 888 MIP- 340 5.8.4 Unsigned32 | M | P | | V | Y | 889 Authenticator-Offset | | | | | | 890 MIP-FA-Challenge 344 5.9 OctetString| M | P | | V | Y | 891 MIP-Feature- 337 5.7 Unsigned32 | M | P | | V | Y | 892 Vector | | | | | | 893 MIP-Foreign- 330 5.10 OctetString| M | P | | V | Y | 894 Agent-FQDN | | | | | | 895 MIP-Home-Agent- 334 5.4 Address | M | P | | V | Y | 896 Address | | | | | | 897 MIP-MN-AAA-Auth 322 5.8 Grouped | M | P | | V | Y | 898 MIP-MN-AAA-SPI 341 5.8.1 Unsigned32 | M | P | | V | Y | 899 MIP-Mobile-Node- 333 5.3 Address | M | P | | V | Y | 900 Address | | | | | | 901 MIP-Previous-FA- 336 5.6 Address | M | P | | V | Y | 902 Addr | | | | | | 903 MIP-Previous-FA- 335 5.5 OctetString| M | P | | V | Y | 904 FQDN | | | | | | 905 MIP-Reg-Request 320 5.1 OctetString| M | P | | V | Y | 906 MIP-Reg-Reply 321 5.2 OctetString| M | P | | V | Y | 908 5.1 MIP-Reg-Request AVP 910 The MIP-Reg-Request AVP (AVP Code 320) is of type OctetString and 911 contains the Mobile IP Registration Request [4] sent by the Mobile 912 Node to the Foreign Agent. 914 5.2 MIP-Reg-Reply AVP 916 The MIP-Reg-Reply AVP (AVP Code 321) is of type OctetString and 917 contains the Mobile IP Registration Reply [4] sent by the Home Agent 918 to the Foreign Agent. 920 5.3 MIP-Mobile-Node-Address AVP 922 The Mobile-Node-Address AVP (AVP Code 333) is of type Address and 923 contains the Mobile Node's Home Address. 925 5.4 MIP-Home-Agent-Address AVP 927 The Home-Agent-Addess AVP (AVP Code 334) is of type Address and 928 contains the Mobile Node's Home Agent Address. 930 5.5 MIP-Previous-FA-FQDN AVP 932 The MIP-Previous-FA-FQDN AVP (AVP Code 335) is of type OctetString 933 and contains the Fully Qualified Domain Name of the Mobile Node's old 934 Foreign Agent, encoded in the UTF-8 [12] format. The Mobile Node MAY 935 include this information in the Registration Request when it moves 936 its point of attachment to a new foreign agent under the same 937 administrative domain as the old FA. 939 When this AVP is present in the AA-Mobile-Node-Request, it indicates 940 that the local Diameter server overseeing the Foreign Agent should 941 attempt to return the registration key that was previously allocated 942 to the old Foreign Agent for the Mobile Node. The registration key is 943 identified through the use of the User-Name AVP, which MUST be 944 present if this extension is present. 946 In many circumstances, this allows the Mobile Node to move from one 947 Foreign Agent to another within the same administrative domain 948 without having to send the request back to the Mobile Node's Home 949 Diameter Server (AAAH). 951 5.6 MIP-Previous-FA-Addr AVP 953 The MIP-Previous-FA-Addr AVP (AVP Code 336) is of type Address and 954 contains the IP Address of the Mobile Node's old Foreign Agent. The 955 Mobile Node MAY include this information in the Previous Foreign 956 Agent Notification Extension to the Mobile IP Registration Request 957 when it moves its point of attachment to a new foreign agent. 959 When this AVP is present in the AA-Mobile-Node-Request, it indicates 960 that the local Diameter server overseeing the Foreign Agent should 961 attempt to return the registration key that was previously allocated 962 to the old Foreign Agent for the Mobile Node. The registration key is 963 identified through the use of the User-Name AVP, which MUST be 964 present if this extension is present. 966 In many circumstances, this allows the Mobile Node to move from one 967 Foreign Agent to another within the same administrative domain 968 without having to send the request back to the Mobile Node's Home 969 Diameter Server (AAAH). 971 5.7 MIP-Feature-Vector AVP 973 The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and 974 is added with flag values set by the Foreign Agent or by the AAAF 975 owned by the same administrative domain as the Foreign Agent. The 976 Foreign Agent SHOULD include MIP-Feature-Vector AVP within the AMR 977 message it sends to the AAAF. 979 Flag values currently defined include: 980 1 Mobile-Node-Home-Address-Requested 981 2 Home-Address-Allocatable-Only-in-Home-Domain 982 4 Home-Agent-Requested 983 8 Foreign-Home-Agent-Available 984 16 MN-HA-Key-Request 985 32 MN-FA-Key-Request 986 64 FA-HA-Key-Request 987 128 Home-Agent-In-Foreign-Network 988 256 Co-Located-Mobile-Node 990 The flags are set according to the following rules. 992 If the mobile node includes a valid home address (i.e., not equal to 993 0.0.0.0 or 255.255.255.255) in its Registration Request, the Foreign 994 Agent zeroes the Mobile-Node-Home-Address-Requested flag in the MIP- 995 Feature-Vector AVP. 997 If the mobile node sets the home address field equal to 0.0.0.0 in 998 its Registration Request, the Foreign Agent sets the Mobile-Node- 999 Home-Address-Requested flag to one. 1001 If the mobile node sets the home agent field equal to 255.255.255.255 1002 in its Registration Request, the Foreign Agent sets both the Home- 1003 Agent-Requested flag and the Home-Address-Allocatable-Only-in-Home- 1004 Domain flag to one in the MIP-Feature-Vector AVP. 1006 If the mobile node sets the home agent field equal to 0.0.0.0 in its 1007 Registration Request, the Foreign Agent sets the Home-Agent-Requested 1008 flag to one, and zeroes the Home-Address-Allocatable-Only-in-Home- 1009 Domain flag in the MIP-Feature-Vector AVP. 1011 Whenever the Foreign Agent sets either the Mobile-Node-Home-Address- 1012 Requested flag or the Home-Agent-Request flag to one, it MUST set the 1013 MN-HA-Key-Request flag to one. The MN-HA-Key-Request flag is also set 1014 to one if the mobile node includes a Generalized MN-HA Key Request 1015 [15] extension, with the subtype set to AAA. 1017 If the mobile node includes a Generalized MN-FA Key Request [15] 1018 extension with the AAA subtype in its Registration Request, the 1019 Foreign Agent sets the MN-FA-Key-Request flag to one in the MIP- 1020 Feature-Vector AVP. 1022 If the mobile node requests a home agent in the foreign network 1023 either by setting the home address field to all ones, or by 1024 specifying a home agent in the foreign network, and the AAAF 1025 authorizes the request, the AAAF MUST set the Home-Agent-In-Foreign- 1026 Network bit to one. 1028 If the Home Agent receives a Registration Request from the Mobile 1029 Node indicating that the MN is acting as a Co-Located Mobile Node, 1030 the Home Agent sets the Co-Located-Mobile-Node bit to one. 1032 If the Foreign Agent's local policy allows it to receive AAA Session 1033 Keys, and it does not have any existing keys with the Home Agent, it 1034 MAY set the FA-HA-Key-Request flag. 1036 The Foreign Agent MUST NOT set the Foreign-Home-Agent-Available, and 1037 Home-Agent-In-Foreign-Network flag to one. 1039 When the AAAF receives the AMR message, it MUST first verify that the 1040 sender was an authorized Foreign Agent. The AAAF then takes any 1041 actions indicated by the settings of the MIP-Feature-Vector AVP 1042 flags. The AAAF then MAY set additional flags. Only the AAAF may 1043 set the Foreign-Home-Agent-Available flag to one. This is done 1044 according to local administrative policy. When the AAAF has finished 1045 setting additional flags according to its local policy, then the AAAF 1046 transmits the AMR with the possibly modified MIP-Feature-Vector AVP 1047 to the AAAH. 1049 5.8 MIP-MN-AAA-Auth AVP 1051 The MN-AAA-Auth AVP (AVP Code 322) is of type Grouped and contains 1052 some ancillary data to simplify processing of the authentication data 1053 in the Mobile IP Registration Request [4] by the target AAA server. 1054 Its value has the following ABNF grammar: 1056 MIP-MN-AAA-Auth = ma-spi authinlen authlen authoffset 1057 ma-spi = ; MIP-MN-AAA-SPI, See Section 5.8.1 1058 authinlen = ; MIP-Auth-Input-Data-Length, / 1059 ; See Section 5.8.2 1060 authlen = ; MIP-Authenticator-Length, / 1061 ; See Section 5.8.3 1062 authoffset = ; MIP-Authenticator-Offset, / 1063 ; See Section 5.8.4 1065 +---------------------------------------------------------------+ 1066 | AVP Header (AVP Code = 322) | 1067 +---------------------------------------------------------------+ 1068 | MIP-MN-AAA-SPI AVP | 1069 +---------------------------------------------------------------+ 1070 | MIP-Auth-Input-Data-Length AVP | 1071 +---------------------------------------------------------------+ 1072 | MIP-Authenticator-Length AVP | 1073 +---------------------------------------------------------------+ 1074 | MIP-Authenticator-Offset AVP | 1075 +---------------------------------------------------------------+ 1077 5.8.1 MIP-MN-AAA-SPI AVP 1079 The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and 1080 indicates the algorithm by which the targeted AAA server (AAAH) 1081 should attempt to validate the Authenticator computed by the mobile 1082 node over the Registration Request data. 1084 5.8.2 MIP-Auth-Input-Data-Length AVP 1086 The MIP-Auth-Input-Data-Length AVP (AVP Code 338) is of type 1087 Unsigned32 and contains the length, in bytes, of the Registration 1088 Request data (data portion of MIP-Reg-Request AVP) that should be 1089 used as input to the algorithm (indicated by the MN-AAA-SPI AVP) used 1090 to determine whether the Authenticator Data supplied by the Mobile 1091 Node is valid. 1093 5.8.3 MIP-Authenticator-Length AVP 1095 The MIP-Authenticator-Length AVP (AVP Code 339) is of type Unsigned32 1096 and contains the length of the authenticator to be validated by the 1097 targeted AAA server (i.e., AAAH). 1099 5.8.4 MIP-Authenticator-Offset AVP 1101 The MIP-Authenticator-Offset AVP (AVP Code 340) is of type Unsigned32 1102 and contains the offset into the Registration Request Data, of the 1103 authenticator to be validated by the targeted AAA server (i.e., 1104 AAAH). 1106 5.9 MIP-FA-Challenge 1108 The MIP-FA-Challenge AVP (AVP Code 344) is of type OctetString and 1109 contains the challenge advertised by the Foreign Agent to the Mobile 1110 Node. This AVP MUST be present in the AMR if the Mobile Node used the 1111 RADIUS-style MN-AAA computation algorithm. 1113 5.10 MIP-Foreign-Agent-FQDN AVP 1115 The MIP-Foreign-Agent-FQDN AVP (AVP Code 330) is of type OctetString 1116 and contains the foreign agent's FQDN, which can be found in the 1117 Origin-FQDN AVP in the AMR. 1119 5.10 Filter-Rule AVP 1121 The Filter-Rule AVP (AVP Code 400) is of type OctetString, encoded in 1122 the UTF-8 [29] format, and provides filter rules that need to be 1123 configured on the Foreign or Home Agent for the user. One or more 1124 such AVPs MAY be present in an authorization response. 1126 Each packet can be filtered based on the following information that 1127 is associated with it: 1129 Direction (in or out) 1130 Source and destination IP address (possibly masked) 1131 Protocol 1132 Source and destination port (lists or ranges) 1133 TCP flags 1134 IP fragment flag 1135 IP options 1136 ICMP types 1138 Rules for the appropriate direction are evaluated in order, with the 1139 first matched rule terminating the evaluation. Each packet is 1140 evaluated once. If no rule matches, the packet is dropped if the last 1141 rule evaluated was a permit, and passed if the last rule was a deny. 1143 The filters in the Filter-Rule AVP MUST follow the format: 1145 action dir proto from src to dst [options] 1147 action permit - Allow packets that match the rule. 1148 deny - Drop packets that match the rule. 1150 dir "in" is from the terminal, "out" is to the terminal. 1152 proto An IP protocol specified by number. The "ip" keyword 1153 means any protocol will match. 1155 src and dst
[ports] 1157 The
may be specified as: 1158 ipno An IPv4 or IPv6 number in dotted-quad or 1159 canonical IPv6 form. Only this exact IP 1160 number will match the rule. 1161 ipno/bits An IP number as above with a mask width of 1162 the form 1.2.3.4/24. In this case all IP 1163 numbers from 1.2.3.0 to 1.2.3.255 will 1164 match. The bit width MUST be valid for 1165 the IP version and the IP number MUST NOT 1166 have bits set beyond the mask. 1168 The sense of the match can be inverted by preceding 1169 an address with the not modifier, causing all other 1170 addresses to be matched instead. This does not 1171 affect the selection of port numbers. 1173 The keyword "any" is 0.0.0.0/0 or the IPv6 1174 equivalent. The keyword "assigned" is the address 1175 or set of addresses assigned to the terminal. The 1176 first rule SHOULD be "deny in ip !assigned". 1178 With the TCP and UDP protocols, optional ports may be 1179 specified as: 1181 {port|port-port}[,port[,...]] 1183 The `-' notation specifies a range of ports 1184 (including boundaries). 1186 Fragmented packets which have a non-zero offset (i.e. 1187 not the first fragment) will never match a rule which 1188 has one or more port specifications. See the frag 1189 option for details on matching fragmented packets. 1191 options: 1192 frag Match if the packet is a fragment and this is not the 1193 first fragment of the datagram. frag may not be used 1194 in conjunction with either tcpflags or TCP/UDP port 1195 specifications. 1197 ipoptions spec 1198 Match if the IP header contains the comma separated 1199 list of options specified in spec. The supported IP 1200 options are: 1202 ssrr (strict source route), lsrr (loose source route), 1203 rr (record packet route) and ts (timestamp). The 1204 absence of a particular option may be denoted with a 1205 `!'. 1207 tcpoptions spec 1208 Match if the TCP header contains the comma separated 1209 list of options specified in spec. The supported TCP 1210 options are: 1212 mss (maximum segment size), window (tcp window 1213 advertisement), sack (selective ack), ts (rfc1323 1214 timestamp) and cc (rfc1644 t/tcp connection count). 1215 The absence of a particular option may be denoted with 1216 a `!'. 1218 established 1219 TCP packets only. Match packets that have the RST or 1220 ACK bits set. 1222 setup TCP packets only. Match packets that have the SYN bit 1223 set but no ACK bit. 1225 tcpflags spec 1226 TCP packets only. Match if the TCP header contains the 1227 comma separated list of flags specified in spec. The 1228 supported TCP flags are: 1230 fin, syn, rst, psh, ack and urg. The absence of a 1231 particular flag may be denoted with a `!'. A rule which 1232 contains a tcpflags specification can never match a 1233 fragmented packet which has a non-zero offset. See the 1234 frag option for details on matching fragmented packets. 1236 icmptypes types 1237 ICMP packets only. Match if the ICMP type is in the 1238 list types. The list may be specified as any 1239 combination of ranges or individual types separated by 1240 commas. The supported ICMP types are: 1242 echo reply (0), destination unreachable (3), source 1243 quench (4), redirect (5), echo request (8), router 1244 advertisement (9), router solicitation (10), time-to- 1245 live exceeded (11), IP header bad (12), timestamp 1246 request (13), timestamp reply (14), information request 1247 (15), information reply (16), address mask request (17) 1248 and address mask reply (18). 1250 There is one kind of packet that the FA MUST always discard, that is 1251 an IP fragment with a fragment offset of one. This is a valid 1252 packet, but it only has one use, to try to circumvent firewalls. 1254 An FA that is unable to interpret or apply a deny rule MUST 1255 terminate the session. An FA that is unable to interpret or apply 1256 a permit rule MAY apply a more restrictive rule. An FA MAY apply 1257 deny rules of its own before the supplied rules, for example to 1258 protect the FA owner's infrastructure. 1260 The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the 1261 ipfw.c code may provide a useful base for implementations. 1263 6.0 Key Distribution Center 1265 The mobile node and mobility agents use registration keys to compute 1266 authentication extensions applied to registration messages, as 1267 defined in [4]: Mobile-Foreign, Foreign-Home and Mobile-Home. If 1268 registration keys are requested the AAA server(s) MUST create them 1269 after the Mobile Node is successfully authenticated and authorized. 1271 If the AAAH does not communicate directly with the foreign agent, and 1272 it does not wish for intermediate proxies to have access to the 1273 session keys, they SHOULD be protected using the end-to-end security 1274 extension [9]. 1276 The Authorization-Lifetime AVP contains the number of seconds before 1277 registration keys destined for the Home Agent and/or Foreign Agent 1278 expire. A value of zero indicates infinity (no timeout). 1280 AAA support for key distribution departs slightly from the existing 1281 SPI usage, as described in [4]. The SPI values are used as key 1282 identifiers, meaning that each registration key has its own SPI 1283 value; nodes that share a key also share an SPI. If no preferred SPI 1284 value is indicated, the AAA server MAY generate SPI values for the 1285 Mobility Agents as opposed to the receiver choosing its own SPI 1286 value. For example, suppose a Mobile Node and a Foreign Agent share a 1287 key that was generated by AAAH with a corresponding SPI value of 1288 37,496. All Mobile-Foreign Authentication extensions will be computed 1289 by either entity (in this example) using the shared key and MUST 1290 include the SPI value of 37,496. 1292 Once the registration keys have been distributed, subsequent Mobile 1293 IP registrations need not invoke the AAA infrastructure until the 1294 keys expire. These registrations MUST include the Mobile-Home 1295 authentication extension. In addition, subsequent registrations MUST 1296 also include Mobile-Foreign authentication extension if the Mobile- 1297 Foreign key was generated and distributed by AAA; similarly for 1298 subsequent use of the Foreign-Home authentication extensions. 1300 Each registration key that is generated by AAA will generally be 1301 distributed to two parties; for instance, a Mobile-Foreign key goes 1302 to both a mobile node and a foreign agent. The methods by which the 1303 key is encoded will depend upon the security associations available 1304 to the AAA server and each recipient of the key. These methods will 1305 often be different for the two recipients, so that the registration 1306 key under consideration has to be encoded twice. 1308 See sections 7.1 and 7.2 for details about the format of the AVPs 1309 used to distribute the registration keys. 1311 6.1 Distributing the Mobile-Home Registration Key 1313 If the mobile node does not have a Mobile-Home registration key, then 1314 the AAAH is likely to be the only entity trusted that is available to 1315 the mobile node. Thus, the AAAH has to generate the Mobile-Home 1316 registration key, and encode it for eventual consumption by the 1317 mobile node and home agent. 1319 If the home agent is in the home domain, then AAAH can directly 1320 encode the Mobile-Home registration key into a MIP-HA-to-MN-Key AVP 1321 and include that AVP in the HAR message for delivery to the home 1322 agent. 1324 If, on the other hand, the home agent is to be allocated in the 1325 visited domain, the AAAH does not transmit the HAR to the home agent, 1326 but instead transmits the HAR to the AAAF. When the AAAF receives the 1327 HAR, it first allocates a home agent, and then issues the HAR for 1328 that home agent. 1330 The AAAH also has to arrange for the key to be delivered to the 1331 mobile node. Unfortunately, the AAA server only knows about Diameter 1332 messages and AVPs, and the mobile node only knows about Mobile IP 1333 messages and extensions[4]. For this purpose, AAAH encodes the 1334 Mobile-Home registration key into a MIP-MN-to-HA-Key AVP, using its 1335 security association with the mobile node, which is added to the HAR 1336 message, and delivered either to a local home agent, or to the AAAF 1337 in the case where the home agent is in the visited network. The AAAH 1338 has to rely on the home agent (that also understands Diameter) to 1339 transfer the key into a Mobile IP Generalized MN-HA Key Reply 1340 extension in the Registration Reply message. The home agent can 1341 format the Reply message and extensions correctly for eventual 1342 delivery to the mobile node. The resulting Registration Reply is 1343 added to the MIP-Reg-Reply AVP and added to the AMA. 1345 After the HAA message is parsed by the AAAH, and transformed into an 1346 AMA, the AMA message containing the MIP-Reg-Reply AVP will eventually 1347 be received by the the foreign agent. The foreign agent can then use 1348 that AVP to recreate a Registration Reply message, containing the 1349 Generalized MN-HA Key Reply extension, for delivery to the mobile 1350 node. 1352 In summary, the AAAH generates the Mobile-Home registration key and 1353 encodes it into a MIP-HA-to-MN-Key AVP and a MIP-MN-to-HA-Key AVP. 1354 These AVPs are delivered to a home agent by including them in a HAR 1355 message sent from either AAAH or AAAF. The home agent decodes the key 1356 for its own use. The home agent also copies the encoded registration 1357 key from the MIP-MN-to-HA-Key AVP into a Generalized MN-HA Key Reply 1358 extension appended to the Mobile IP Registration Reply message. This 1359 Registration Reply message MUST also include the Mobile-Home 1360 authentication extension, created using the newly allocated Mobile- 1361 Home registration key. The home agent then encodes the Registration 1362 Reply message and extensions into a MIP-Reg-Reply AVP included as 1363 part of the HAA message to be sent back to the AAA server. 1365 6.2 Distributing the Mobile-Foreign Registration Key 1367 The Mobile-Foreign registration key is also generated by AAAH (upon 1368 request), so that it can be encoded into a MIP-MN-to-FA-Key AVP, 1369 which is added to the HAR, and copied by the home agent into a 1370 Generalized MN-FA Key Reply Extension [15] to the Mobile IP 1371 Registration Reply message. Most of the considerations for 1372 distributing the Mobile-Foreign registration key are similar to the 1373 distribution of the Mobile-Home Registration Key. 1375 If the MIP-FA-to-MN-Key AVP is present in the HAR, the home agent 1376 MUST ensure that the same AVP is present in the HAA. The AAAH MUST 1377 ensure that this AVP is present in the AMA, which is sent to the 1378 foreign agent. The foreign agent MUST include the FA-MN 1379 Authentication extension to the Registration Reply, using the decoded 1380 session key found in MIP-FA-to-MN-Key. 1382 6.3 Distributing the Foreign-Home Registration Key 1384 If the home agent is in the home domain, then AAAH has to generate 1385 the Foreign-Home registration key. Otherwise, it is generated by 1386 AAAF. 1388 In either case, the AAA server encodes the registration key into a 1389 MIP-HA-to-FA-Key AVP and includes that AVP as part of the HAR message 1390 sent to the home agent, and waits for the HAA message to be returned. 1392 If the MIP-FA-to-HA-Key AVP was present in the HAR, the same AVP MUST 1393 be present in the corresponding HAA, which is eventually transformed 1394 by the AAAH into an AMA message that is transmitted back to the 1395 foreign agent. 1397 Upon receipt of the HAR, the home agent recovers the Foreign-Home 1398 registration key, and uses this key to create a Foreign-Home 1399 authentication extension to the Registration Reply message. 1401 6.4 Key Distribution Example 1403 Figure 9 provides an example of subsequent Mobile IP message 1404 exchange, assuming that AAAH distributed registration keys for all 1405 three MN-FA, FA-HA and HA-MN authentication extensions. 1407 Mobile Node Foreign Agent Home Agent 1408 ----------- ------------- ---------- 1410 Reg-Req(MN-HA-Auth, MN-FA-Auth)--------> 1412 Reg-Req(MN-HA-Auth, FA-HA-Auth)--------> 1414 <--------Reg-Rep(MN-HA-Auth, FA-HA-Auth) 1416 <--------Reg-Rep(MN-HA-Auth, MN-FA-Auth) 1418 Figure 9: Mobile IP Message Exchange 1420 7.0 Key Distribution Center (KDC) AVPs 1422 The Mobile-IP protocol defines a set of security associations shared 1423 between the Mobile Node, Foreign Agent and Home Agents. These three 1424 security associations (Mobile-Home, Mobile-Foreign, and Foreign- 1425 Home), can be dynamically created by the AAAH. This requires that the 1426 AAAH create Mobile-IP Registration Keys, and that these keys be 1427 distributed to the three mobile entities, via the Diameter Protocol. 1429 AAA servers supporting the Diameter Mobile IP Extension MUST 1430 implement the KDC AVPs defined in this document. In other words, AAA 1431 servers MUST be able to create three registration keys: the Mobile- 1432 Home, Mobile-Foreign, and Foreign-Home keys. 1434 The names of the KDC AVPs indicate the two entities sharing the 1435 security association defined by the encrypted key material; the 1436 intended receiver of the AVP is the first named entity. So, for 1437 instance, the MIP-MN-to-HA-Key AVP contains the Mobile-Home key 1438 encrypted in a way that allows it to be recovered by the mobile node. 1440 If strong authentication and confidentiality of the registration keys 1441 is required, it is recommended that the end-to-end security extension 1442 [9] be used. 1444 The following table describes the Diameter AVPs defined in the Mobile 1445 IP extension, their AVP Code values, types, possible flag values and 1446 whether the AVP MAY be encrypted. 1448 +---------------------+ 1449 | AVP Flag rules | 1450 |----+-----+----+-----|----+ 1451 AVP Section | | |SHLD| MUST|MAY | 1452 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 1453 -----------------------------------------|----+-----+----+-----|----| 1454 MIP-Algorithm- 345 7.2.7 Unsigned32 | M | P | | V | Y | 1455 Type | | | | | | 1456 MIP-FA-HA- 327 7.4 Unsigned32 | M | P | | V | Y | 1457 Preferred-SPI | | | | | | 1458 MIP-FA-MN- 324 7.3 Unsigned32 | M | P | | V | Y | 1459 Preferred-SPI | | | | | | 1460 MIP-FA-to-HA-Key 328 7.2.2 Grouped | M | P | | V | Y | 1461 MIP-FA-to-MN-Key 326 7.2.1 Grouped | M | P | | V | Y | 1462 MIP-HA-to-FA-Key 329 7.2.3 Grouped | M | P | | V | Y | 1463 MIP-HA-to-MN-Key 332 7.2.4 Grouped | M | P | | V | Y | 1464 MIP-MN-to-FA-Key 325 7.1.1 OctetString| M | P | | V | Y | 1465 MIP-MN-to-HA-Key 331 7.1.2 OctetString| M | P | | V | Y | 1466 MIP-Peer-SPI 342 7.2.5 Unsigned32 | M | P | | V | Y | 1467 MIP-Replay-Mode 346 7.2.8 Unsigned32 | M | P | | V | Y | 1468 MIP-Session-Key 343 7.2.6 OctetString| M | P | | V | Y | 1470 7.1 Mobile Node Registration Keys 1472 When the AAAH acts as a Key Distribution Center, and it is determined 1473 that keying material is to be created for Mobile Nodes, the AAAH 1474 creates the keys and encodes them in the MIP-MN-to-FA-Key and MIP- 1475 MN-to-HA-Key AVPs as opaque data. The actual format of the AVP value 1476 is described in [15], and would contains the data immediately 1477 following the Mobile IP extension header. 1479 The Mobile IP key described in [15] refers to the AAA SPI, which MUST 1480 be set to the value the AAAH shares with the Mobile Node. The Key 1481 Lifetime field is set to the same value as the one found in the 1482 Authorization-Lifetime AVP. 1484 7.1.1 MIP-MN-to-FA-Key AVP 1486 The MIP-MN-to-FA-Key AVP (AVP Code 325) is of type OctetString, and 1487 contains the Keying material described in the "Unsolicited MN-FA Key 1488 from AAA Subtype" in [15]. The FA SPI field of the data structure in 1489 [15] MUST be set to the same value as the MIP-Peer-SPI AVP within the 1490 FA-to-MN-Key AVP. 1492 7.1.2 MIP-MN-to-HA-Key AVP 1494 The MIP-MN-to-HA-Key AVP (AVP Code 331) is of type OctetString, and 1495 contains the Keying material described in the "Unsolicited MN-HA Key 1496 from AAA Subtype" in [15]. The HA SPI field of the data structure in 1497 [15] MUST be set to the same value as the MIP-Peer-SPI AVP within the 1498 HA-to-MN-Key AVP. 1500 7.2 Mobility Agent Session Keys 1502 The Mobility Agent session keys are the keys created by a Diameter 1503 server, which it distributes to Foreign and Home Agents, acting as 1504 Diameter clients. The lifetime of the generated keys MUST be the 1505 same as the value of the Authorization-Lifetime AVP. These session 1506 keys, described below, are of type Grouped, and therefore their value 1507 have the following ABNF format: 1509 Mobility Agent Session Key AVP = Peer-SPI Algorithm-Type / 1510 Replay-Mode Session-Key 1511 Peer-SPI = ; MIP-Peer-SPI, See Section 7.2.5 1512 Algorithm-Type = ; MIP-Algorithm-Type, See Section 7.2.7 1513 Replay-Mode = ; MIP-Replay-Mode, See Section 7.2.8 1514 Session-Key = ; MIP-Session-Key, See Section 7.2.6 1516 The MIP-Peer-SPI AVP contains the Security Parameter Index, which the 1517 Mobility Agent MUST use to refer to the Key contained in the MIP- 1518 Session-Key AVP. The Algorithm-Type AVP identifies the cryptographic 1519 function to be used in the creation of the relevant Mobile IP 1520 authentication extension. The Reply-Mode AVP specifies the replay 1521 method used in the generation of the Mobile IP registration messages. 1523 +---------------------------------------------------------------+ 1524 | AVP Header (AVP Code = see below) | 1525 +---------------------------------------------------------------+ 1526 | MIP-Peer-SPI AVP | 1527 +---------------------------------------------------------------+ 1528 | Algorithm-Type AVP | 1529 +---------------------------------------------------------------+ 1530 | Replay-Mode AVP | 1531 +---------------------------------------------------------------+ 1532 | MIP-Session-Key AVP | 1533 +---------------------------------------------------------------+ 1535 7.2.1 MIP-FA-to-MN-Key AVP 1537 The MIP-FA-to-MN-Key AVP (AVP Code 326) is of type Grouped, and 1538 contains the Foreign Agent's session key, which it shares with the 1539 Mobile Node. Its format is described in Section 7.2. 1541 7.2.2 MIP-FA-to-HA-Key AVP 1543 The MIP-FA-to-HA-Key AVP (AVP Code 328) is of type Grouped, and 1544 contains the Foreign Agent's session key, which it shares with the 1545 Home Agent. Its format is described in Section 7.2. 1547 7.2.3 MIP-HA-to-FA-Key AVP 1549 The MIP-HA-to-FA-Key AVP (AVP Code 329) is of type Grouped, and 1550 contains the Home Agent's session key, which it shares with the 1551 Foreign Agent. Its format is described in Section 7.2. 1553 7.2.4 MIP-HA-to-MN-Key AVP 1555 The MIP-HA-to-MN-Key AVP (AVP Code 332) is of type Grouped, and 1556 contains the Home Agent's session key, which it shares with the 1557 Mobile Node. Its format is described in Section 7.2. 1559 7.2.5 MIP-Peer-SPI AVP 1561 The MIP-Peer-SPI AVP (AVP Code 342) is of type Unsigned32, and 1562 contains the Security Parameter Index to use to reference the key in 1563 the associated MIP-Session-Key AVP. 1565 7.2.6 MIP-Session-Key AVP 1567 The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and 1568 contains the Session Key to be used between two Mobile IP entities. 1570 7.2.7 MIP-Algorithm-Type AVP 1572 The MIP-Algorithm-Type AVP (AVP Code 345) is of type Unsigned32, and 1573 contains the Algorithm identifier used to generate the associated 1574 Mobile IP authentication extension. The following values are 1575 currently defined: 1577 0 Prefix+Suffix MD5 1578 1 HMAC-MD5 1580 7.2.8 MIP-Replay-Mode AVP 1582 The MIP-Replay-Mode AVP (AVP Code 346) is of type Unsigned32 and 1583 contains the replay mode the Home Agent should use when 1584 authenticating the Mobile Node. Although present in the Grouped AVPs 1585 sent to the Foreign Agent, this field is ignored. 1587 The following values are supported (see [4] for more information): 1589 0 None 1590 1 Timestamps 1591 2 Nonces 1593 7.3 MIP-FA-MN-Preferred-SPI AVP 1595 The MIP-FA-MN-Preferred-SPI AVP (AVP Code 324) is of type Unsigned32 1596 and is sent in the AA-Mobile-Node-Request by the Foreign Agent. The 1597 AVP contains the SPI that the Foreign Agent would prefer to have 1598 assigned by the AAAH in the MIP-FA-to-MN-Key AVP. 1600 7.4 MIP-FA-HA-Preferred-SPI AVP 1602 The MIP-FA-HA-Preferred-SPI AVP (AVP Code 327) is of type Unsigned32 1603 and is sent in the AA-Mobile-Node-Request by the Foreign Agent. The 1604 AVP contains the SPI that the Foreign Agent would prefer to have 1605 assigned by the AAAH in the MIP-FA-to-HA-Key AVP. 1607 8.0 Accounting AVPs 1608 This section will define the Accounting AVPs that are specific to 1609 Mobile IP, and MUST be included in all Accounting-Request messages. 1610 These AVPs MAY be present in the corresponding Accounting-Answer 1611 messages as well. 1613 8.1 Accounting-Input-Octets AVP 1615 The Accounting-Input-Octets AVP (AVP Code 42) is of type Unsigned64, 1616 and contains the number of octets in IP packets received from the 1617 user. 1619 8.2 Accounting-Output-Octets AVP 1621 The Accounting-Output-Octets AVP (AVP Code 43) is of type Unsigned64, 1622 and contains the number of octets in IP packets sent to the user. 1624 8.3 Accounting-Session-Time AVP 1626 The Accounting-Session-Time AVP (AVP Code 46) is of type Unsigned32, 1627 and indicates the length of the current session in seconds. 1629 8.4 Accounting-Input-Packets AVP 1631 The Accounting-Input-Packets (AVP Code 47) is of type Unsigned64, and 1632 contains the number of IP packets received from the user. 1634 8.5 Accounting-Output-Packets AVP 1636 The Accounting-Output-Packets (AVP Code 48) is of type Unsigned64, 1637 and contains the number of IP packets sent to the user. 1639 9.0 Interactions with Resource Management 1641 The Resource Management extension [2] provides the ability for a 1642 Diameter node to query a peer for session state information. The 1643 document states that service-specific extensions are responsible for 1644 specifying what AVPs are to be present in the Resource-Token [2] AVP. 1646 In addition to the AVPs listed in [2], the Resource-Token AVP MUST 1647 include the MIP-Mobile-Node-Address and the MIP-Home-Agent-Address 1648 AVPs. 1650 10.0 AVP Occurrence Tables 1652 The following tables presents the AVPs defined in this document, and 1653 specifies in which Diameter messages they MAY, or MAY NOT be present. 1654 Note that AVPs that can only be present within a Grouped AVP are not 1655 represented in this table. 1657 The table uses the following symbols: 1658 0 The AVP MUST NOT be present in the message. 1659 0+ Zero or more instances of the AVP MAY be present in the 1660 message. 1661 0-1 Zero or one instance of the AVP MAY be present in the 1662 message. 1663 1 One instance of the AVP MUST be present in the message. 1665 10.1 Mobile IP Command AVP Table 1667 The table in this section is limited to the Command Codes defined in 1668 this specification. 1670 +-----------------------+ 1671 | Command-Code | 1672 |-----+-----+-----+-----+ 1673 Attribute Name | AMR | AMA | HAR | HAA | 1674 ------------------------------|-----+-----+-----+-----+ 1675 Authorization-Lifetime | 0-1 | 1 | 1 | 1 | 1676 Destination-FQDN | 0-1 | 1 | 0-1 | 1 | 1677 Destination-Realm | 1 | 0 | 1 | 0 | 1678 Error-Reporting-FQDN | 0 | 0-1 | 0 | 0-1 | 1679 Auth-Extension-Id | 1 | 1 | 1 | 1 | 1680 Filter-Rule | 0 | 0+ | 0+ | 0 | 1681 MIP-FA-Challenge | 0-1 | 0 | 0 | 0 | 1682 MIP-FA-to-HA-Key | 0 | 0-1 | 0-1 | 0-1 | 1683 MIP-FA-to-MN-Key | 0 | 0-1 | 0-1 | 0-1 | 1684 MIP-FA-HA-Preferred-SPI | 0-1 | 0 | 0 | 0 | 1685 MIP-FA-MN-Preferred-SPI | 0-1 | 0 | 0 | 0 | 1686 MIP-Feature-Vector | 0-1 | 0 | 0 | 0 | 1687 MIP-Foreign-Agent-FQDN | 0 | 0 | 1 | 1 | 1688 MIP-HA-to-FA-Key | 0 | 0 | 0-1 | 0 | 1689 MIP-HA-to-MN-Key | 0 | 0 | 0-1 | 0 | 1690 MIP-Home-Agent-Address | 0-1 | 0-1 | 0-1 | 0-1 | 1691 MIP-MN-AAA-Auth | 1 | 0 | 0 | 0 | 1692 MIP-MN-to-FA-Key | 0 | 0 | 0-1 | 0 | 1693 MIP-MN-to-HA-Key | 0 | 0-1 | 0-1 | 0 | 1694 MIP-Mobile-Node-Address | 0-1 | 0-1 | 0-1 | 0-1 | 1695 MIP-Previous-FA-Address | 0-1 | 0 | 0 | 0 | 1696 MIP-Previous-FA-FQDN | 0-1 | 0 | 0 | 0 | 1697 MIP-Reg-Reply | 0 | 0-1 | 0 | 0-1 | 1698 MIP-Reg-Request | 1 | 0 | 1 | 0 | 1699 Origin-FQDN | 1 | 1 | 1 | 1 | 1700 Origin-Realm | 1 | 1 | 1 | 1 | 1701 Proxy-Info | 0+ | 0+ | 0+ | 0+ | 1702 Result-Code | 0 | 1 | 0 | 1 | 1703 Route-Record | 0+ | 0+ | 0+ | 0+ | 1704 Session-Id | 1 | 1 | 1 | 1 | 1705 Session-Timeout | 0 | 1 | 1 | 1 | 1706 User-Name | 1 | 0 | 1 | 0 | 1707 ------------------------------|-----+-----+-----+-----| 1709 10.2 Accounting AVP Table 1710 The table in this section is used to represent which AVPs defined in 1711 this document are to be present in the Accounting messages, defined 1712 in [1]. 1714 +-------------+ 1715 | Command-Code| 1716 |------+------+ 1717 Attribute Name | ACR | ACA | 1718 ------------------------------|------+------+ 1719 Accounting-Input-Octets | 1 | 0-1 | 1720 Accounting-Input-Packets | 1 | 0-1 | 1721 Accounting-Output-Octets | 1 | 0-1 | 1722 Accounting-Output-Packets | 1 | 0-1 | 1723 Accounting-Session-Time | 1 | 0-1 | 1724 MIP-Feature-Vector | 1 | 0-1 | 1725 MIP-Home-Agent-Address | 1 | 0-1 | 1726 MIP-Mobile-Node-Address | 1 | 0-1 | 1727 MIP-Previous-FA-Address | 0-1 | 0-1 | 1728 MIP-Previous-FA-FQDN | 0-1 | 0-1 | 1729 ------------------------------|------+------+ 1731 11.0 Acknowledgements 1733 The authors would like to thank Nenad Trifunovic, Haseeb Akhtar and 1734 Pankaj Patel for their participation in the Document Reading Party, 1735 to Erik Guttman for his very useful proposed text, and to Tony 1736 Johansson for the proposed text AND being in the doc reading party. 1737 The authors would also like to thank the participants of 3GPP2's 1738 TSG-P working group for their valuable feedback. 1740 The following people have contributed text to this document: Fredrik 1741 Johansson, Martin Julien 1743 12.0 IANA Considerations 1745 This section contains the namespaces that have either been created in 1746 this specification, or the values assigned to existing namespaces 1747 managed by IANA. 1749 12.1 Command Codes 1751 This specification assigns the values 260 and 262 from the Command 1752 Code namespace defined in [1], and extended in [9] and [14]. See 1753 section 2.0 for the assignment of the namespace in this 1754 specification. 1756 12.2 AVP Codes 1758 This specification assigns the values 320-322, 324-346 from the AVP 1759 Code namespace defined in [1], and extended in [9] and [14]. See 1760 sections 5.0 and 7.0 for the assignment of the namespace in this 1761 specification. 1763 This specification also makes use of AVP Code 400, which is assigned 1764 in [14]. 1766 12.3 Result-Code AVP Values 1768 This specification assigns the values 4004-4006 from the Result-Code 1769 AVP (AVP Code 268) value namespace defined in [1], and extended in 1770 [9]. See section 3.0 for the assignment of the namespace in this 1771 specification. 1773 12.4 DSI-Event AVP Values 1775 This specification assigns the values 4002-4003 and 5009 from the 1776 DSI-Event AVP (AVP Code 297) value namespace defined in [1]. See 1777 section 4.0 for the assignment of the namespace in this 1778 specification. 1780 12.5 MIP-Feature-Vector AVP Values 1782 There are 32 bits in the MIP-Feature-Vector AVP (AVP Code 337) that 1783 are available for assignment. This document assigns bits 1-9, as 1784 listed in section 5.7. The remaining bits should only be assigned via 1785 Standards Action [14]. 1787 12.6 MIP-Algorithm-Type AVP Values 1789 As defined in Section 7.2.7, the MIP-Algorithm-Type AVP (AVP Code 1790 345) defines the values 0-1. All remaining values are available for 1791 assignment via Designated Expert [14]. 1793 12.7 MIP-Replay-Mode AVP Values 1795 As defined in Section 7.2.8, the MIP-Replay-Mode AVP (AVP Code 346) 1796 defines the values 0-2. All remaining values are available for 1797 assignment via Designated Expert [14]. 1799 12.8 Extension Identifier 1801 This specification assigns the value four (4) to the Extension 1802 Identifier namespace defined in [1]. See section 1.7 for more 1803 information. 1805 13.0 Security Considerations 1807 This specification describes the Diameter extension necessary to 1808 authenticate and authorize a Mobile IP Mobile Node. The 1809 authentication algorithm used is dependent upon the transforms 1810 available by the Mobile IP protocol, and [5]. This specification also 1811 defines a method by which the home Diameter server can create and 1812 distribute registration keys to be used to authenticate Mobile IP 1813 registration messages. The keys SHOULD be be protected using the 1814 methods defined in [9]. 1816 14.0 References 1818 [1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "Diameter Base 1819 Protocol", draft-ietf-aaa-diameter-04.txt, IETF work in pro- 1820 gress, May 2001. 1822 [2] P. Calhoun, "Diameter Resource Management", draft-calhoun- 1823 diameter-res-mgmt-06.txt, IETF Work in Progress, February 2001. 1825 [3] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, 1826 Authorization, and Accounting Requirements". RFC 2977. October 1827 2000. 1829 [4] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. 1831 [5] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response Exten- 1832 sions". RFC 3012. November 2000. 1834 [6] B. Aboba, M. Beadles "The Network Access Identifier." RFC 2486. 1835 January 1999. 1837 [7] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", 1838 RFC 2477, January 1999. 1840 [8] P. Calhoun, C. Perkins, "Mobile IP Network Address Identifier 1841 Extension", RFC 2794, March 2000. 1843 [9] P. Calhoun, W. Bulley, S. Farrell, "Diameter End-2-End Security 1844 Extensions", draft-ietf-aaa-diameter-e2e-sec-02.txt, IETF work 1845 in progress, May 2001. 1847 [10] Kent, Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 1848 2406, November 1998. 1850 [11] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1851 Levels", BCP 14, RFC 2119, March 1997. 1853 [12] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 1854 2279, January 1998. 1856 [13] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing 1857 for Message Authentication. RFC 2104, February 1997. 1859 [14] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASREQ 1860 Extension", draft-ietf-aaa-diameter-nasreq-04.txt, IETF work in 1861 progress, May 2001. 1863 [15] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile IP", 1864 draft-ietf-aaa-mobileip-aaa-key-05.txt, IETF work in progress, 1865 May 2001. 1867 [16] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA", 1868 draft-hiller-cdma2000-aaa-01.txt, IETF work in progress, June 1869 2000. 1871 [17] Narten, Alvestrand,"Guidelines for Writing an IANA Considera- 1872 tions Section in RFCs", BCP 26, RFC 2434, October 1998 1874 15.0 Authors' Addresses 1876 Questions about this memo can be directed to: 1878 Pat R. Calhoun 1879 Network and Security Research Center, Sun Labs 1880 Sun Microsystems, Inc. 1881 15 Network Circle 1882 Menlo Park, California, 94025 1883 USA 1885 Phone: +1 650-786-7733 1886 Fax: +1 650-786-6445 1887 E-mail: pcalhoun@eng.sun.com 1888 Charles E. Perkins 1889 Nokia Research Center 1890 313 Fairchild Drive 1891 Mountain View, California 94043 1892 USA 1894 Phone: +1 650-625-2986 1895 Fax: +1 650-625-2502 1896 E-Mail: charliep@iprg.nokia.com 1898 16.0 Full Copyright Statement 1900 Copyright (C) The Internet Society (2001). All Rights Reserved. 1902 This document and translations of it may be copied and furnished to 1903 others, and derivative works that comment on or otherwise explain it 1904 or assist in its implementation may be prepared, copied, published 1905 and distributed, in whole or in part, without restriction of any 1906 kind, provided that the above copyright notice and this paragraph are 1907 included on all such copies and derivative works. However, this docu- 1908 ment itself may not be modified in any way, such as by removing the 1909 copyright notice or references to the Internet Society or other 1910 Internet organizations, except as needed for the purpose of develop- 1911 ing Internet standards in which case the procedures for copyrights 1912 defined in the Internet Standards process must be followed, or as 1913 required to translate it into languages other than English. The lim- 1914 ited permissions granted above are perpetual and will not be revoked 1915 by the Internet Society or its successors or assigns. This document 1916 and the information contained herein is provided on an "AS IS" basis 1917 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 1918 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 1919 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1920 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1921 FITNESS FOR A PARTICULAR PURPOSE. 1923 17.0 Expiration Date 1925 This memo is filed as and 1926 expires in October 2001.