idnits 2.17.1 draft-ietf-aaa-diameter-mobileip-06.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 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. == 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 (June 2001) is 8345 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 1826, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1832, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1835, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-05 ** 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-00 -- 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-05 == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-aaa-key-05 -- 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') Summary: 16 errors (**), 0 flaws (~~), 15 warnings (==), 5 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 June 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-Domain 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-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 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-Previous-FA-Host AVP 71 4.6 MIP-Previous-FA-Addr AVP 72 4.7 MIP-Feature-Vector AVP 73 4.8 MIP-MN-AAA-Auth AVP 74 4.8.1 MIP-MN-AAA-SPI AVP 75 4.8.2 MIP-Auth-Input-Data-Length AVP 76 4.8.3 MIP-Authenticator-Length AVP 77 4.8.4 MIP-Authenticator-Offset AVP 78 4.9 MIP-FA-Challenge AVP 79 4.10 MIP-Foreign-Agent-Host AVP 80 5.0 Key Distribution Center 81 5.1 Distributing the Mobile-Home Registration Key 82 5.2 Distributing the Mobile-Foreign Registration Key 83 5.3 Distributing the Foreign-Home Registration Key 84 5.4 Key Distribution Example 85 6.0 Key Distribution Center (KDC) AVPs 86 6.1 Mobile Node Session Keys 87 6.1.1 MIP-MN-to-FA-Key AVP 88 6.1.2 MIP-MN-to-HA-Key AVP 89 6.2 Mobility Agent Session Keys 90 6.2.1 MIP-FA-to-MN-Key AVP 91 6.2.2 MIP-FA-to-HA-Key AVP 92 6.2.3 MIP-HA-to-FA-Key AVP 93 6.2.4 MIP-HA-to-MN-Key AVP 94 6.2.5 MIP-Peer-SPI AVP 95 6.2.6 MIP-Session-Key AVP 96 6.2.7 MIP-Algorithm-Type AVP 97 6.2.8 MIP-Replay-Mode AVP 98 6.3 FA-MN-Preferred-SPI AVP 99 6.4 FA-HA-Preferred-SPI AVP 100 7.0 Accounting AVPs 101 7.1 Accounting-Input-Octets AVP 102 7.2 Accounting-Output-Octets AVP 103 7.3 Accounting-Session-Time AVP 104 7.4 Accounting-Input-Packets AVP 105 7.5 Accounting-Output-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 DSI-Event AVP Values 115 10.5 MIP-Feature-Vector AVP Values 116 10.6 MIP-Algorithm-Type AVP Values 117 10.7 MIP-Replay-Mode AVP Values 118 10.8 Application Identifier 119 11.0 Security Considerations 120 12.0 References 121 13.0 Authors' Addresses 122 14.0 Full Copyright Statement 123 15.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-Domain 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 registration 159 keys are created and distributed to the mobility entities for the 160 purposes 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 The Diameter Mobile-IP Application meets the requirements specified 171 in [3, 16]. Later subsections in this introductory section provide 172 some examples and message flows of the Mobile IP and Diameter 173 messages that occur when a Mobile Node requests service in a foreign 174 network. In this document, the role of the "attendant" [3] is 175 performed by either the home agents (for co-located mobile nodes) or 176 foreign agents for the Mobile-IP Application, and these terms will be 177 used interchangeably. 179 1.1 Requirements language 181 In this document, the key words "MAY", "MUST", "MUST NOT", 182 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 183 interpreted as described in [11]. 185 1.2 Inter-Domain Mobile IP 187 When a Mobile Node node requests service by issuing a Registration 188 Request to the foreign agent, the foreign agent creates the AA- 189 Mobile-Node-Request (AMR) message, which includes the AVPs defined in 190 section 2.1. The Home Address, Home Agent, Mobile Node NAI and other 191 important fields are extracted from the registration messages for 192 possible inclusion as Diameter AVPs. The AMR message is then 193 forwarded to the local Diameter server, known as the AAA-Foreign, or 194 AAAF. 196 Visited Domain Home Domain 197 +--------+ +--------+ 198 |abc.com | AMR/AMA |xyz.com | 199 | AAAF |<------------------->| AAAH | 200 +->| server | server-server | server | 201 | +--------+ communication +--------+ 202 | ^ ^ 203 | AMR/AMA | client-server | HAR/HAA 204 | | communication | 205 v v v 206 +---------+ +---------+ +---------+ 207 | Foreign | | Foreign | | Home | 208 | Agent | | Agent | | Agent | 209 +---------+ +---------+ +---------+ 210 ^ 211 | Mobile IP 212 | 213 v 214 +--------+ 215 | Mobile | 216 | Node | mn@xyz.com 217 +--------+ 218 Figure 1: Inter-Domain Mobility 220 Upon receiving the AMR, the AAAF follows the procedures outlined in 221 [1] to determine whether the AMR should be processed locally, or if 222 it should be forwarded to another Diameter Server, known as the AAA- 223 Home, or AAAH. Figure 1 shows an example in which a mobile node 224 (mn@xyz.com) requests service from a foreign provider (abc.com). The 225 request received by the AAAF is forwarded to xyz.com's AAAH server. 227 Figure 2 shows the message flows involved when the foreign agent 228 invokes the AAA infrastructure to request that a mobile node be 229 authenticated and authorized. Note that it is not required that the 230 foreign agent invoke AAA services every time a Registration Request 231 is received from the mobile, but rather only when the prior 232 authorization from the AAAH expires. The expiration time of the 233 authorization (and registration keys, if allocated by the AAA server) 234 is communicated through the Authorization-Lifetime AVP in the AA- 235 Mobile-Node-Answer (AMA, see section 2.2) from the AAAH. 237 Mobile Node Foreign Agent AAAF AAAH Home Agent 238 ----------- ------------- ------------ ---------- ---------- 239 Advertisement & 240 <--------- Challenge 242 Reg-Req&MN-AAA ----> 244 AMR------------> 245 Session-Id = foo 247 AMR------------> 248 Session-Id = foo 250 HAR-----------> 251 Session-Id = bar 253 <----------HAA 254 Session-Id = bar 256 <-----------AMA 257 Session-Id = foo 259 <------------AMA 260 Session-Id = foo 262 <-------Reg-Reply 264 Figure 2: Mobile IP/Diameter Message Exchange 266 The foreign agent (as shown in Figure 2) MAY provide a challenge, 267 which gives it direct control over the replay protection in the 268 Mobile IP registration process, as described in [5]. The mobile node 269 includes the Challenge and MN-AAA authentication extension to enable 270 authorization by AAAH. If the authentication data supplied in the 271 MN-AAA extension is invalid, AAAH returns the response (AMA) with the 272 Result-Code AVP set to DIAMETER_ERROR_AUTH_FAILURE (see section 3.0). 274 In the event that the AMR generated by the FA is for a session that 275 has was previously authorized by the AAAH, it MUST include the 276 Destination-Host AVP, with the identity of the AAAH. The AAAH's 277 identity can be retrieved from the Origin-Host AVP in the last AMA 278 received for the session. 280 If the Mobile Node was successfully authenticated, the AAAH checks if 281 the Home Agent was located in the foreign domain, by checking the 282 Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. If 283 the flag is enabled, then the Home Agent is located in the foreign 284 domain then AAAH sends an HAR message to AAAF which contains a MIP- 285 Reg-Request AVP. 287 If the Home Agent was not located in the foreign domain, the AAAH 288 checks for the MIP-Home-Agent-Address AVP. If one was specified, the 289 AAAH checks that the address is that of a known Home Agent, and one 290 that the Mobile Node is allowed to request, and the Home Agent's 291 identity is included in the Destination-Host AVP. If no Home Agent 292 was specified, and if the MIP-Feature-Vector has the Home-Agent- 293 Requested flag set, and if allowed by policy in the home domain, the 294 AAAH SHOULD allocate a home agent on behalf of the Mobile Node. This 295 can be done in a variety of ways, including using a load balancing 296 algorithm in order to keep the load on all home agents equal. The 297 actual algorithm used and the method of discovering the home agents 298 is outside the scope of this specification. 300 The AAAH then sends an Home-Agent-MIP-Request (HAR), which contains 301 the Mobile IP Registration Request message data encapsulated in the 302 MIP-Reg-Request AVP, to the assigned or requested Home Agent. The 303 AAAH MAY allocate a home address for the mobile node, and include it 304 in a MIP-Mobile-Node-Address AVP within the HAR, or else leave this 305 allocation responsibility for the Home Agent. 307 For new sessions, the AAAH MUST create an accounting session 308 identifier, which is added to the Accounting-Multi-Session-Id AVP in 309 the HAR message sent to the home agent. 311 During the creation of the HAR, the AAAH MUST use a different session 312 identifier than the one used in the AMR/AMA (see figure 2). Of 313 course, the AAAH MUST use the same session identifier for all HARs 314 initiated on behalf of a given mobile node's session. A mobile node's 315 session is identified via its identity in the User-Name AVP, the 316 MIP-Mobile-Node-Address and MIP-Home-Agent-Address AVPs. This is 317 necessary in order to allow the session state machine, defined in the 318 base protocol [1], to be used unmodified with this application. 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 Accounting-Multi-Session-Id AVP in 339 the HAR MUST be included in the HAA, which is then forwarded to the 340 AAAH. 342 Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer 343 (AMA) message, includes the Accounting-Multi-Session-Id that was 344 present in the HAA, and the MIP-Home-Agent-Address, MIP-Mobile-Node- 345 Address AVPs in the AMA message, enabling appropriate firewall 346 controls for the penetration of tunneled traffic between the Home 347 Agent and the Mobile Node. 349 The AAAF is responsible for ensuring that the AMA message is properly 350 forwarded to the correct foreign agent. 352 1.3 Support for Mobile IP Handoffs 354 Given the nature of Mobile IP, a mobile node MAY receive service from 355 many foreign agents during a period of time. However, the Home Domain 356 should not view these handoffs as different sessions, since this 357 could affect billing systems. Furthermore, many foreign agents do not 358 communicate, which makes it quite difficult for AAA information to be 359 exchanged between these entities. Therefore, it MUST be assumed that 360 a foreign agent is not aware that a registration request from a 361 mobile node has been previously authorized. 363 The first registration request from a mobile node will therefore 364 cause an AMR to be sent to its AAAF. The AMR will include a new 365 session identifier, and MAY even be sent to a different AAAF in the 366 visited network. It is also quite likely that the AMR will be 367 received by a different AAAH. 369 Since the new AAAH in the home network MAY not have access to the 370 session identifier that was used by the old AAAH, it is necessary for 371 the resulting HAR received by the HA to be identified as a 372 continuation of an existing session. If the HA receives an HAR for a 373 mobile node, with a new session identifier, and the HA can guarantee 374 that this request is to extend service for an existing service, then 375 the HA MUST be able to modify its internal session state information 376 to reflect the new AAAH and session identifier. The HA MUST also 377 issue an STR message with the old session identifier to the AAAH it 378 was communicating with when using the old session identifier. 380 It is necessary for accounting records to have some commonality 381 across handoffs in order for correlation to occur. Therefore, in the 382 event that a home agent receives an HAR with a different Accounting- 383 Multi-Session-id AVP (and obviously a different Session-Id AVP), the 384 home agent MUST send an HAA with the Accounting-Multi-Session-Id AVP 385 that was received by the AAAH in the first HAR for the mobile's 386 session. This modified Accounting-Multi-Session-Id AVP will be 387 returned to the foreign agent by the AAAH in the AMA. Both the 388 foreign and home agents MUST include the Accounting-Multi-Session-Id 389 in the accounting messages. 391 ACR, Session-Id = foo ACR, Session-Id = bar 392 Accounting-Multi-Session-Id = a Accounting-Multi-Session-Id = a 393 ---------------------> <-------------------- 394 +----+ +------+ +------+ +----+ 395 | FA | | AAAF | | AAAH | | HA | 396 +----+ +------+ +------+ +----+ 397 <--------------------- ---------------------> 398 ACA, Session-Id = foo ACA, Session-Id = bar 400 Figure 4: Accounting messages w/ Mobile IP Application 402 1.4 Allocation of Home Agent in Foreign Network 404 The Diameter Mobile IP application allows a Home Agent to be 405 allocated in a foreign network, as required in [3, 16]. When a 406 foreign agent detects that the mobile node has a home agent address 407 equal to 0.0.0.0 or 255.255.255.255 in the Registration Request 408 message, it MUST add a MIP-Feature-Vector AVP with the Home-Agent- 409 Requested flag set to one. If the home agent address is equal to 410 255.255.255.255, then the foreign agent also MUST set the Home- 411 Address-Allocatable-Only-in-Home-Domain flag equal to one. If the 412 home agent address is set to 0.0.0.0, the foreign agent MUST set the 413 Home-Address-Allocatable-Only-in-Home-Domain flag equal to zero. 415 When the AAAF receives a AMR message with the Home-Agent-Requested 416 flag set to one, and the Home-Address-Allocatable-Only-in-Home-Domain 417 flag equal to zero, AAAF MAY set the Foreign-Home-Agent-Available 418 flag in the MIP-Feature-Vector AVP to inform the AAAH that it is 419 willing and able to assign a Home Agent for the Mobile Node. 421 In the event that the mobile node requests a home agent in the 422 foreign network, and the AAAF authorizes its use, the AAAF MUST set 423 the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. 424 This could happen when the AAA request is sent to "extend" a mobile 425 node's current session. 427 When the AAAH receives a AMR message, it first checks the 428 authentication data supplied by the mobile node, according to the 429 MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether 430 to authorize the mobile node. If the AMR indicates that the AAAF has 431 offered to allocate a home agent for the mobile node, then the AAAH 432 must decide whether its local policy would allow the user to have a 433 Home Agent in the foreign network. If so, and after checking 434 authorization from the data in the AMR message, the AAAH sends the 435 HAR message to the AAAF that does not contain the MIP-Home-Agent- 436 Address. The AAAF MUST allocate a Home Agent, if one has not already 437 been assigned to the Mobile Node, and the AAAF forwards the HAR 438 message to the Home Agent. 440 Visited Home 441 Domain Domain 442 +--------+ ------- AMR -------> +--------+ 443 | AAAF | <------ HAR -------- | AAAH | 444 | | | | 445 +--->| server | ------- HAA -------> | server | 446 | +--------+ <------ AMA -------- +--------+ 447 | ^ | 448 | | | 449 HAR/HAA | AMR | | AMA 450 v | v 451 +---------+ +---------+ 452 | Home | | Foreign | 453 | Agent | | Agent | 454 +---------+ +---------+ 455 ^ 456 +--------+ | 457 | Mobile |<----------+ 458 | Node | Mobile IP 459 +--------+ 460 Figure 5: Home Agent allocated in Visited Domain 462 Upon receipt of a HAA from the Home Agent in the Visited Domain, with 463 the Result-Code AVP indicating success, the AAAF forwards the HAA to 464 the AAAH in the home domain. The AMA is then constructed, and issued 465 to the AAAF, and finally to the FA. The HAA and AMA MUST include the 466 MIP-Home-Agent-Address and the MIP-Mobile-Node-Address AVPs. 468 Mobile Node Foreign Agent Home Agent AAAF AAAH 469 ----------- ------------- ------------- ---------- ---------- 471 <----Challenge---- 472 Reg-Req (Response)-> 473 ------------AMR-------------> 474 -----AMR----> 475 <----HAR----- 476 <-----HAR------ 477 ------HAA------> 478 -----HAA----> 479 <----AMA----- 480 <-------------AMA------------ 481 <---Reg-Reply---- 482 Figure 6: Mobile IP/Diameter Message Exchange 484 If the Mobile Node moves to another Foreign Network, it MAY either 485 request to keep the same Home Agent within the old foreign network, 486 or request to get a new one in the new foreign network. If the AAAH 487 is willing to provide the requested service, the mobile node will 488 have to interact with two AAAFs. 490 Figure 7 shows the message flows for a Mobile Node requesting to keep 491 the Home Agent assigned in Foreign network 1 when it moves to foreign 492 network 2. Upon reception of the AMR in Foreign network 2, the AAAF 493 follows the procedures described earlier and forwards AMR to the 494 Mobile Node's home network, i.e. its AAAH. If the Mobile Node was 495 successfully authenticated the AAAH checks for the Origin-Host and 496 the MIP-Previous-FA-Host AVPs. If a AAAH deduces that the Mobile Node 497 has moved to a new domain, it must check whether the Mobile can still 498 use the previously assigned Home Agent. 500 +---------------+ +---------------+ +-------------+ 501 |Foreign net 2 | |Foreign net 1 | |Home network | 502 | | | | | | 503 Mobile Node | FA AAAF | | HA AAAF | | AAAH | 504 ----------- | ---- ---- | | ---- ------ | | ------ | 505 +---------------+ +---------------+ +-------------+ 507 <----Challenge---- 508 Reg-Req (Response)-> 509 ---AMR---> 510 ----------------AMR---------------> 511 <-----HAR----- 512 <---HAR---- 513 ----HAA---> 514 ------HAA----> 515 <---------------AMA---------------- 516 <--AMA---- 517 <----Reg-Reply----- 518 Figure 7: Request to access Home Agent from new Foreign Network 520 If the Mobile Node is allowed to keep the Home Agent the AAAH then 521 sends a HAR, which contains the Mobile IP Registration Request 522 message data encapsulated in the MIP-Reg-Request AVP and the MIP- 523 Home-Agent-Address AVP with Home Agent address, as well as any 524 optional KDC session keys, to the AAAF in foreign network 1. Upon 525 reception the AAAF in foreign network 1 will forward the HAR to the 526 Home Agent if its local policy allows such service. If the AAAF does 527 not permit such service, it MUST return a 528 DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. 530 When the AAAF receives a successful HAA, the AAAF will forward the 531 HAA back to the AAAH. The HAA MUST include the MIP-Home-Agent-Address 532 and the MIP-Mobile-Node-Address AVPs. The AAAH will then send back an 533 AMA to the AAAF in foreign network 2. 535 If the old Foreign Network does not permit the use of its Home Agent 536 when the Mobile Node moves to a new foreign network, the AAAH or AAAF 537 MUST return an AMA with the Result-Code AVP set to 538 DIAMETER_ERROR_HA_NOT_AVAILABLE. Upon receipt of this error, the 539 Foreign Agent MUST issue a Mobile IP Registration Reply to the Mobile 540 Node with an appropriate error. The Mobile Node MAY attempt to 541 request that a new Home Agent and Address be allocated. When the AAAH 542 transmits such an error, it MUST issue a Diameter Abort-Session- 543 Request message to the AAAF overseeing the Home Agent to enable it to 544 release any resources. 546 1.5 Co-located Mobile Node 547 In the event that a Mobile Node registers with the Home Agent as a 548 co-located Mobile Node, there is no Foreign Agent involved. 549 Therefore, when the Home Agent receives the Registration Request, an 550 AMR message is sent to the local AAAH server, with the Co-Located- 551 Mobile-Node bit set in the MIP-Feature-Vector AVP. 553 Home 554 Domain 555 +--------+ 556 | AAAH | 557 | | 558 | server | 559 +--------+ 560 ^ | 561 | | 562 AMR | | AMA 563 | v 564 +--------+ +---------+ 565 | Mobile | Registration | Home | 566 | Node |-------------->| Agent | 567 +--------+ Request +---------+ 568 Figure 8: Co-located Mobile Node 570 If the MN-HA-Key-Requested bit was set in the AMR message from 571 the Home Agent, the Home Agent and Mobile Node's session keys 572 would be present in the AMA message. 574 1.6 Diameter Session Termination 576 A Foreign and Home Agent following this specification MAY expect 577 their respective Diameter servers to maintain session state 578 information for each mobile node in their networks. In order for the 579 Diameter Server to release any resources allocated to a specific 580 mobile node, the mobility agents MUST send a Session-Termination- 581 Request (STR) [1] to their respective Diameter servers. 583 The Home Diameter server SHOULD only deallocate all resources after 584 the STR is received from the Home Agent. This ensures that a Mobile 585 Node that moves from one Foreign Agent to another (hand-off) does not 586 cause the Home Diameter Server to free all resources for the Mobile 587 Node. 589 In the event that the AAAF wishes to terminate a session, its Abort- 590 Session-Request (ASR) [1] message SHOULD be sent to the FA. 591 Similarly, the AAAH SHOULD send its message to the Home Agent. 593 1.7 Advertising application support 595 Diameter nodes conforming to this specification MAY advertise support 596 by including the value of four (4) in the Auth-Application-Id or the 597 Acct-Application-Id AVP of the Capabilities-Exchange-Request and 598 Capabilities-Exchange-Answer command [1]. 600 1.8 Fast Handoff support 602 This application requires that foreign agents issue an AMR upon 603 receipt of the first registration message from a mobile node, 604 regardless of the fact that the mobile node MAY have been previously 605 authorized to another foreign agent. 607 The Mobile IP Working Group is currently investigating fast handoff 608 proposals, and the Seamoby WG is looking at creating a protocol that 609 would allow AAA state information to be exchange between foreign 610 agents during a handoff. These proposals MAY allow future 611 enhancements to the Diameter protocol, in order to reduce the amount 612 of Diameter exchanges required during a handoff. 614 2.0 Command-Code Values 616 This section defines Command-Code [1] values that MUST be supported 617 by all Diameter implementations conforming to this specification. 618 The following Command Codes are defined in this specification: 620 Command-Name Abbreviation Code Section 621 ----------------------------------------------------------- 622 AA-Mobile-Node-Answer AMA 260 2.2 623 AA-Mobile-Node-Request AMR 260 2.1 624 Home-Agent-MIP-Answer HAA 262 2.4 625 Home-Agent-MIP-Request HAR 262 2.3 627 2.1 AA-Mobile-Node-Request 629 The AA-Mobile-Node-Request (AMR), indicated by the Command-Code field 630 set to 260 and the 'R' bit set in the Command Flags field, is sent by 631 an attendant, acting as a Diameter client, to a server in order to 632 request the authentication and authorization of a Mobile Node. The 633 Foreign Agent (or Home Agent in the case of a co-located Mobile Node) 634 uses information found in the Registration Request to construct the 635 following AVPs that are to be included as part of the AMR: 637 home address (MIP-Mobile-Node-Address AVP), 638 home agent address (MIP-Home-Agent-Address AVP), 639 mobile node NAI (User-Name AVP [1]). 640 MN-HA Key Request (MIP-Feature-Vector AVP) 641 MN-FA Key Request (MIP-Feature-Vector AVP) 642 MN-AAA Authentication Extension 643 Foreign Agent Challenge Extension 645 If the mobile node's home address is zero, the foreign or home agent 646 MUST NOT include a MIP-Mobile-Node-Address AVP in the AMR. If the 647 home agent address is zero or all ones, the MIP-Home-Agent-Address 648 AVP MUST NOT be present in the AMR. 650 If a Foreign Agent is used in a visited network, the AAAF MAY set the 651 Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP in 652 the AMR message to indicate that it is willing to assign a Home Agent 653 in the visited domain. 655 If the MIP-Previous-FA-Host AVP is found in the request, the Diameter 656 client requests that the server return the registration key that was 657 assigned to the previous Foreign Agent for use with the Mobile Node 658 and Home Agent. The registration key is identified through the use of 659 the User-Name AVP. 661 Message Format 663 ::= < Diameter Header: 260, REQ, PXY > 664 < Session-ID > 665 { Auth-Application-Id } 666 { User-Name } 667 { Destination-Realm } 668 { Origin-Host } 669 { Origin-Realm } 670 { MIP-Reg-Request } 671 { MIP-MN-AAA-Auth } 672 [ MIP-Mobile-Node-Address ] 673 [ MIP-Home-Agent-Address ] 674 [ MIP-Feature-Vector ] 675 [ Authorization-Lifetime ] 676 [ MIP-FA-MN-Preferred-SPI ] 677 [ MIP-FA-HA-Preferred-SPI ] 678 [ MIP-Previous-FA-Host ] 679 [ MIP-Previous-FA-Addr ] 680 [ MIP-FA-Challenge ] 681 [ Destination-Host ] 682 [ Origin-State-Id ] 683 * [ AVP ] 684 * [ Proxy-Info ] 685 * [ Route-Record ] 687 2.2 AA-Mobile-Node-Answer 689 The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code field 690 set to 261 and the 'R' bit cleared in the Command Flags field, is 691 sent by the AAAH in response to the AA-Mobile-Node-Request message. 692 The Result-Code AVP MAY contain one of the values defined in section 693 3.0, in addition to the values defined in [1]. 695 An AMA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST 696 include the MIP-Home-Agent-Address, MIP-Home-Mobile-Node-Address and 697 MIP-Reg-Reply AVPs. The MIP-Home-Agent-Address AVP contains the Home 698 Agent assigned to the Mobile Node, while the MIP-Mobile-Node-Address 699 AVP contains the home address that was assigned. The AMA message MUST 700 contain the MIP-FA-to-HA-Key, MIP-FA-to-MN-Key if they were requested 701 in the AMR, and they were present in the HAR. The MIP-MN-to-HA-Key 702 and MIP-HA-to-MN-Key AVPs MUST be present if the session keys were 703 requested in the AMR, and the Co-Located-Mobile-Node bit was set in 704 the MIP-Feature-Vector AVP. 706 An AMA message with the Result-Code AVP set to 707 DIAMETER_LIMITED_SUCCESS MAY include the MIP-Home-Agent-Address AVP 708 if a dynamically assigned home agent was requested by the mobile 709 node. Upon receipt of this result code, the foreign agent MUST issue 710 the Registration Request to the Home Agent in the manner described in 711 [4]. 713 An AMA message with the Result-Code set to DIAMETER_MULTI_ROUND_AUTH 714 MAY include mobile node registration key AVPs (see Section 6.1) such 715 as the MIP-MN-to-FA-Key AVP and the MIP-MN-to-HA-Key AVP. If such an 716 AVP is present in the AMA message, the foreign agent MUST include the 717 corresponding Mobile IP key distribution extension in the 718 Registration Reply it sends to the mobile node. This is to support 719 multi-roundtrip authentication mechanisms. 721 Message Format 723 ::= < Diameter Header: 260, PXY > 724 < Session-Id > 725 { Auth-Application-Id } 726 { Authorization-Lifetime } 727 { Result-Code } 728 { Origin-Host } 729 { Origin-Realm } 730 { Destination-Host } 731 { Accounting-Multi-Session-Id } 732 [ Error-Reporting-Host ] 733 [ MIP-Reg-Reply ] 734 [ MIP-MN-to-FA-Key ] 735 [ MIP-MN-to-HA-Key ] 736 [ MIP-FA-to-MN-Key ] 737 [ MIP-FA-to-HA-Key ] 738 [ MIP-HA-to-MN-Key ] 739 [ MIP-Home-Agent-Address ] 740 [ MIP-Mobile-Node-Address ] 741 * [ Filter-Rule ] 742 [ Session-Timeout ] 743 [ Origin-State-Id ] 744 * [ AVP ] 745 * [ Proxy-Info ] 746 * [ Route-Record ] 748 2.3 Home-Agent-MIP-Request 750 The Home-Agent-MIP-Request (HAR), indicated by the Command-Code field 751 set to 262 and the 'R' bit set in the Command Flags field, is sent by 752 the AAA to the Home Agent. If the Home Agent is to be assigned in a 753 foreign network, the HAR is issued by the AAAH and forwarded by the 754 AAAF. If the HAR message does not include a MIP-Mobile-Node-Address 755 AVP, and the Registration Request has 0.0.0.0 for the home address, 756 and the HAR is successfully processed, the Home Agent MUST allocate 757 one such address to the mobile node. If the home agent's local AAA 758 server allocates the mobile node's home address, it MUST include the 759 assigned address in an MIP-Mobile-Node-Address AVP. 761 When registration keys are requested for use by the mobile node (see 762 section 5.0), the AAAH MUST create them and include them in the HAR 763 message. When a Foreign-Home registration key is requested, it will 764 be created and distributed by the AAA server in the same domain as 765 the home agent. 767 Message Format 769 ::= < Diameter Header: 262, REQ, PXY > 770 < Session-Id > 771 { Auth-Application-Id } 772 { Authorization-Lifetime } 773 { MIP-Reg-Request } 774 { Origin-Host } 775 { Origin-Realm } 776 { User-Name } 777 { Destination-Realm } 778 { Accounting-Multi-Session-Id } 779 { MIP-Foreign-Agent-Host } 780 [ Destination-Host ] 781 [ MIP-MN-to-HA-Key ] 782 [ MIP-MN-to-FA-Key ] 783 [ MIP-HA-to-MN-Key ] 784 [ MIP-HA-to-FA-Key ] 785 [ MIP-FA-to-MN-Key ] 786 [ MIP-FA-to-HA-Key ] 787 [ MIP-Mobile-Node-Address ] 788 [ MIP-Home-Agent-Address ] 789 * [ Filter-Rule ] 790 [ Session-Timeout ] 791 [ Origin-State-Id ] 792 * [ AVP ] 793 * [ Proxy-Info ] 794 * [ Route-Record ] 796 2.4 Home-Agent-MIP-Answer 798 The Home-Agent-MIP-Answer (HAA), indicated by the Command-Code field 799 set to 262 and the 'R' bit cleared in the Command Flags field, is 800 sent by the Home Agent to its local AAA server in response to a 801 Home-Agent-MIP-Request. If the home agent allocated a home address 802 for the Mobile Node, the address MUST be included in the MIP-Mobile- 803 Node-Address AVP. The Result-Code AVP MAY contain one of the values 804 defined in section 3.0 instead of the values defined in [1]. 806 Message Format 808 ::= < Diameter Header: 262, PXY > 809 < Session-Id > 810 { Auth-Application-Id } 811 { Session-Timeout } 812 { Authorization-Lifetime } 813 { Result-Code } 814 { Origin-Host } 815 { Origin-Realm } 816 { Destination-Host } 817 { Accounting-Multi-Session-Id } 818 { MIP-Foreign-Agent-Host } 819 [ Error-Reporting-Host ] 820 [ MIP-Reg-Reply ] 821 [ MIP-Home-Agent-Address ] 822 [ MIP-Mobile-Node-Address ] 823 [ MIP-FA-to-MN-Key ] 824 [ MIP-FA-to-HA-Key ] 825 [ Filter-Rule ] 826 [ Origin-State-Id ] 827 * [ AVP ] 828 * [ Proxy-Info ] 829 * [ Route-Record ] 831 3.0 Result-Code AVP Values 833 This section defines new Result-Code [1] values that MUST be 834 supported by all Diameter implementations that conform to this 835 specification. 837 3.1 Transient Failures 839 Errors that fall within the transient failures category are used to 840 inform a peer that the request could not be satisfied at the time it 841 was received, but MAY be able to satisfy the request in the future. 843 DIAMETER_ERROR_AUTH_FAILURE 4004 844 This error code is used by AAAH to inform the attendant that 845 the authentication data in the MN-AAA authentication extension 846 is invalid. 848 DIAMETER_ERROR_MIP_REPLY_FAILURE 4005 849 This error code is used by the Home Agent when processing of 850 the Registration Request has failed. 852 DIAMETER_ERROR_HA_NOT_AVAILABLE 4006 853 This error code is used to inform the Foreign Agent that the 854 requested Home Agent cannot be assigned to the Mobile Node at 855 this time. The Foreign Agent MUST return a Mobile IP 856 Registration Reply to the Mobile Node with an appropriate error 857 code. 859 DIAMETER_ERROR_BAD_KEY 4007 860 This error code is used by the Home Agent to indicate to the 861 local Diameter server that the key generated is invalid. 863 3.2 Permanent Failures 865 Errors that fall within the permanent failures category are used to 866 inform the peer that the request failed, and should not be attempted 867 again. 869 DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE 5018 870 This error is used by the AAAF to inform the AAAH that 871 allocation of a Home Agent in the Foreign Agent is not 872 permitted at this time. 874 4.0 Mandatory AVPs 876 The following table describes the Diameter AVPs defined in the Mobile 877 IP application, their AVP Code values, types, possible flag values 878 and whether the AVP MAY be encrypted. 880 +---------------------+ 881 | AVP Flag rules | 882 |----+-----+----+-----|----+ 883 AVP Section | | |SHLD| MUST|MAY | 884 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 885 -----------------------------------------|----+-----+----+-----|----| 886 Filter-Rule 400 4.10 OctetString| M | P | | V | Y | 887 MIP-Auth-Input- 338 4.8.2 Unsigned32 | M | P | | V | Y | 888 Data-Length | | | | | | 889 MIP- 339 4.8.3 Unsigned32 | M | P | | V | Y | 890 Authenticator-Length | | | | | | 891 MIP- 340 4.8.4 Unsigned32 | M | P | | V | Y | 892 Authenticator-Offset | | | | | | 893 MIP-FA-Challenge 344 4.9 OctetString| M | P | | V | Y | 894 MIP-Feature- 337 4.7 Unsigned32 | M | P | | V | Y | 895 Vector | | | | | | 896 MIP-Foreign- 330 4.10 OctetString| M | P | | V | Y | 897 Agent-Host | | | | | | 898 MIP-Home-Agent- 334 4.4 IPAddress | M | P | | V | Y | 899 Address | | | | | | 900 MIP-MN-AAA-Auth 322 4.8 Grouped | M | P | | V | Y | 901 MIP-MN-AAA-SPI 341 4.8.1 Unsigned32 | M | P | | V | Y | 902 MIP-Mobile-Node- 333 4.3 IPAddress | M | P | | V | Y | 903 Address | | | | | | 904 MIP-Previous-FA- 336 4.6 IPAddress | M | P | | V | Y | 905 Addr | | | | | | 906 MIP-Previous-FA- 335 4.5 OctetString| M | P | | V | Y | 907 Host | | | | | | 908 MIP-Reg-Request 320 4.1 OctetString| M | P | | V | Y | 909 MIP-Reg-Reply 321 4.2 OctetString| M | P | | V | Y | 911 4.1 MIP-Reg-Request AVP 913 The MIP-Reg-Request AVP (AVP Code 320) is of type OctetString and 914 contains the Mobile IP Registration Request [4] sent by the Mobile 915 Node to the Foreign Agent. 917 4.2 MIP-Reg-Reply AVP 919 The MIP-Reg-Reply AVP (AVP Code 321) is of type OctetString and 920 contains the Mobile IP Registration Reply [4] sent by the Home Agent 921 to the Foreign Agent. 923 4.3 MIP-Mobile-Node-Address AVP 924 The Mobile-Node-Address AVP (AVP Code 333) is of type IPAddress and 925 contains the Mobile Node's Home Address. 927 4.4 MIP-Home-Agent-Address AVP 929 The Home-Agent-Addess AVP (AVP Code 334) is of type IPAddress and 930 contains the Mobile Node's Home Agent Address. 932 4.5 MIP-Previous-FA-Host AVP 934 The MIP-Previous-FA-Host AVP (AVP Code 335) is of type 935 DiameterIdentity and contains the identity of the Mobile Node's old 936 Foreign Agent. The Mobile Node MAY include this information in the 937 Registration Request when it moves its point of attachment to a new 938 foreign agent under the same administrative domain as the old FA. 940 When this AVP is present in the AA-Mobile-Node-Request, it indicates 941 that the local Diameter server overseeing the Foreign Agent should 942 attempt to return the registration key that was previously allocated 943 to the old Foreign Agent for the Mobile Node. The registration key is 944 identified through the use of the User-Name AVP, which MUST be 945 present if this extension is present. 947 In many circumstances, this allows the Mobile Node to move from one 948 Foreign Agent to another within the same administrative domain 949 without having to send the request back to the Mobile Node's Home 950 Diameter Server (AAAH). 952 4.6 MIP-Previous-FA-Addr AVP 954 The MIP-Previous-FA-Addr AVP (AVP Code 336) is of type IPAddress and 955 contains the IP Address of the Mobile Node's old Foreign Agent. The 956 Mobile Node MAY include this information in the Previous Foreign 957 Agent Notification Extension to the Mobile IP Registration Request 958 when it moves its point of attachment to a new foreign agent. 960 When this AVP is present in the AA-Mobile-Node-Request, it indicates 961 that the local Diameter server overseeing the Foreign Agent should 962 attempt to return the registration key that was previously allocated 963 to the old Foreign Agent for the Mobile Node. The registration key is 964 identified through the use of the User-Name AVP, which MUST be 965 present if this extension is present. 967 In many circumstances, this allows the Mobile Node to move from one 968 Foreign Agent to another within the same administrative domain 969 without having to send the request back to the Mobile Node's Home 970 Diameter Server (AAAH). 972 4.7 MIP-Feature-Vector AVP 974 The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and 975 is added with flag values set by the Foreign Agent or by the AAAF 976 owned by the same administrative domain as the Foreign Agent. The 977 Foreign Agent SHOULD include MIP-Feature-Vector AVP within the AMR 978 message it sends to the AAAF. 980 Flag values currently defined include: 981 1 Mobile-Node-Home-Address-Requested 982 2 Home-Address-Allocatable-Only-in-Home-Domain 983 4 Home-Agent-Requested 984 8 Foreign-Home-Agent-Available 985 16 MN-HA-Key-Request 986 32 MN-FA-Key-Request 987 64 FA-HA-Key-Request 988 128 Home-Agent-In-Foreign-Network 989 256 Co-Located-Mobile-Node 991 The flags are set according to the following rules. 993 If the mobile node includes a valid home address (i.e., not equal to 994 0.0.0.0 or 255.255.255.255) in its Registration Request, the Foreign 995 Agent zeroes the Mobile-Node-Home-Address-Requested flag in the MIP- 996 Feature-Vector AVP. 998 If the mobile node sets the home address field equal to 0.0.0.0 in 999 its Registration Request, the Foreign Agent sets the Mobile-Node- 1000 Home-Address-Requested flag to one. 1002 If the mobile node sets the home agent field equal to 255.255.255.255 1003 in its Registration Request, the Foreign Agent sets both the Home- 1004 Agent-Requested flag and the Home-Address-Allocatable-Only-in-Home- 1005 Domain flag to one in the MIP-Feature-Vector AVP. 1007 If the mobile node sets the home agent field equal to 0.0.0.0 in its 1008 Registration Request, the Foreign Agent sets the Home-Agent-Requested 1009 flag to one, and zeroes the Home-Address-Allocatable-Only-in-Home- 1010 Domain flag in the MIP-Feature-Vector AVP. 1012 Whenever the Foreign Agent sets either the Mobile-Node-Home-Address- 1013 Requested flag or the Home-Agent-Request flag to one, it MUST set the 1014 MN-HA-Key-Request flag to one. The MN-HA-Key-Request flag is also set 1015 to one if the mobile node includes a Generalized MN-HA Key Request 1017 [15] extension, with the subtype set to AAA. 1019 If the mobile node includes a Generalized MN-FA Key Request [15] 1020 extension with the AAA subtype in its Registration Request, the 1021 Foreign Agent sets the MN-FA-Key-Request flag to one in the MIP- 1022 Feature-Vector AVP. 1024 If the mobile node requests a home agent in the foreign network 1025 either by setting the home address field to all ones, or by 1026 specifying a home agent in the foreign network, and the AAAF 1027 authorizes the request, the AAAF MUST set the Home-Agent-In-Foreign- 1028 Network bit to one. 1030 If the Home Agent receives a Registration Request from the Mobile 1031 Node indicating that the MN is acting as a Co-Located Mobile Node, 1032 the Home Agent sets the Co-Located-Mobile-Node bit to one. 1034 If the Foreign Agent's local policy allows it to receive AAA Session 1035 Keys, and it does not have any existing keys with the Home Agent, it 1036 MAY set the FA-HA-Key-Request flag. 1038 The Foreign Agent MUST NOT set the Foreign-Home-Agent-Available, and 1039 Home-Agent-In-Foreign-Network flag to one. 1041 When the AAAF receives the AMR message, it MUST first verify that the 1042 sender was an authorized Foreign Agent. The AAAF then takes any 1043 actions indicated by the settings of the MIP-Feature-Vector AVP 1044 flags. The AAAF then MAY set additional flags. Only the AAAF may 1045 set the Foreign-Home-Agent-Available flag to one. This is done 1046 according to local administrative policy. When the AAAF has finished 1047 setting additional flags according to its local policy, then the AAAF 1048 transmits the AMR with the possibly modified MIP-Feature-Vector AVP 1049 to the AAAH. 1051 4.8 MIP-MN-AAA-Auth AVP 1053 The MN-AAA-Auth AVP (AVP Code 322) is of type Grouped and contains 1054 some ancillary data to simplify processing of the authentication data 1055 in the Mobile IP Registration Request [4] by the target AAA server. 1056 Its value has the following ABNF grammar: 1058 MIP-MN-AAA-Auth ::= < AVP Header: 322 > 1059 { MIP-MN-AAA-SPI } 1060 { MIP-Auth-Input-Data-Length } 1061 { MIP-Authenticator-Length } 1062 { MIP-Authenticator-Offset } 1063 * [ AVP ] 1065 4.8.1 MIP-MN-AAA-SPI AVP 1067 The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and 1068 indicates the algorithm by which the targeted AAA server (AAAH) 1069 should attempt to validate the Authenticator computed by the mobile 1070 node over the Registration Request data. 1072 4.8.2 MIP-Auth-Input-Data-Length AVP 1074 The MIP-Auth-Input-Data-Length AVP (AVP Code 338) is of type 1075 Unsigned32 and contains the length, in bytes, of the Registration 1076 Request data (data portion of MIP-Reg-Request AVP) that should be 1077 used as input to the algorithm (indicated by the MN-AAA-SPI AVP) used 1078 to determine whether the Authenticator Data supplied by the Mobile 1079 Node is valid. 1081 4.8.3 MIP-Authenticator-Length AVP 1083 The MIP-Authenticator-Length AVP (AVP Code 339) is of type Unsigned32 1084 and contains the length of the authenticator to be validated by the 1085 targeted AAA server (i.e., AAAH). 1087 4.8.4 MIP-Authenticator-Offset AVP 1089 The MIP-Authenticator-Offset AVP (AVP Code 340) is of type Unsigned32 1090 and contains the offset into the Registration Request Data, of the 1091 authenticator to be validated by the targeted AAA server (i.e., 1092 AAAH). 1094 4.9 MIP-FA-Challenge 1096 The MIP-FA-Challenge AVP (AVP Code 344) is of type OctetString and 1097 contains the challenge advertised by the Foreign Agent to the Mobile 1098 Node. This AVP MUST be present in the AMR if the Mobile Node used the 1099 RADIUS-style MN-AAA computation algorithm. 1101 4.10 MIP-Foreign-Agent-Host AVP 1103 The MIP-Foreign-Agent-Host AVP (AVP Code 330) is of type 1104 DiameterIdentity and contains the identity of the foreign agent. This 1105 AVP is copied from the value of the Origin-Host AVP in the AMR. 1107 4.10 Filter-Rule AVP 1109 The Filter-Rule AVP (AVP Code 400) is of type UTF8String, and 1110 provides filter rules that need to be configured on the Foreign or 1111 Home Agent for the user. One or more such AVPs MAY be present in an 1112 authorization response. 1114 Each packet can be filtered based on the following information that 1115 is associated with it: 1117 Direction (in or out) 1118 Source and destination IP address (possibly masked) 1119 Protocol 1120 Source and destination port (lists or ranges) 1121 TCP flags 1122 IP fragment flag 1123 IP options 1124 ICMP types 1126 Rules for the appropriate direction are evaluated in order, with the 1127 first matched rule terminating the evaluation. Each packet is 1128 evaluated once. If no rule matches, the packet is dropped if the last 1129 rule evaluated was a permit, and passed if the last rule was a deny. 1131 The filters in the Filter-Rule AVP MUST follow the format: 1133 action dir proto from src to dst [options] 1135 action permit - Allow packets that match the rule. 1136 deny - Drop packets that match the rule. 1138 dir "in" is from the terminal, "out" is to the terminal. 1140 proto An IP protocol specified by number. The "ip" keyword 1141 means any protocol will match. 1143 src and dst
[ports] 1145 The
may be specified as: 1146 ipno An IPv4 or IPv6 number in dotted-quad or 1147 canonical IPv6 form. Only this exact IP 1148 number will match the rule. 1149 ipno/bits An IP number as above with a mask width of 1150 the form 1.2.3.4/24. In this case all IP 1151 numbers from 1.2.3.0 to 1.2.3.255 will 1152 match. The bit width MUST be valid for 1153 the IP version and the IP number MUST NOT 1154 have bits set beyond the mask. 1156 The sense of the match can be inverted by preceding 1157 an address with the not modifier, causing all other 1158 addresses to be matched instead. This does not 1159 affect the selection of port numbers. 1161 The keyword "any" is 0.0.0.0/0 or the IPv6 1162 equivalent. The keyword "assigned" is the address 1163 or set of addresses assigned to the terminal. The 1164 first rule SHOULD be "deny in ip !assigned". 1166 With the TCP and UDP protocols, optional ports may be 1167 specified as: 1169 {port|port-port}[,port[,...]] 1171 The `-' notation specifies a range of ports 1172 (including boundaries). 1174 Fragmented packets which have a non-zero offset (i.e. 1175 not the first fragment) will never match a rule which 1176 has one or more port specifications. See the frag 1177 option for details on matching fragmented packets. 1179 options: 1180 frag Match if the packet is a fragment and this is not the 1181 first fragment of the datagram. frag may not be used 1182 in conjunction with either tcpflags or TCP/UDP port 1183 specifications. 1185 ipoptions spec 1186 Match if the IP header contains the comma separated 1187 list of options specified in spec. The supported IP 1188 options are: 1190 ssrr (strict source route), lsrr (loose source route), 1191 rr (record packet route) and ts (timestamp). The 1192 absence of a particular option may be denoted with a 1193 `!'. 1195 tcpoptions spec 1196 Match if the TCP header contains the comma separated 1197 list of options specified in spec. The supported TCP 1198 options are: 1200 mss (maximum segment size), window (tcp window 1201 advertisement), sack (selective ack), ts (rfc1323 1202 timestamp) and cc (rfc1644 t/tcp connection count). 1203 The absence of a particular option may be denoted with 1204 a `!'. 1206 established 1207 TCP packets only. Match packets that have the RST or 1208 ACK bits set. 1210 setup TCP packets only. Match packets that have the SYN bit 1211 set but no ACK bit. 1213 tcpflags spec 1214 TCP packets only. Match if the TCP header contains the 1215 comma separated list of flags specified in spec. The 1216 supported TCP flags are: 1218 fin, syn, rst, psh, ack and urg. The absence of a 1219 particular flag may be denoted with a `!'. A rule which 1220 contains a tcpflags specification can never match a 1221 fragmented packet which has a non-zero offset. See the 1222 frag option for details on matching fragmented packets. 1224 icmptypes types 1225 ICMP packets only. Match if the ICMP type is in the 1226 list types. The list may be specified as any 1227 combination of ranges or individual types separated by 1228 commas. The supported ICMP types are: 1230 echo reply (0), destination unreachable (3), source 1231 quench (4), redirect (5), echo request (8), router 1232 advertisement (9), router solicitation (10), time-to- 1233 live exceeded (11), IP header bad (12), timestamp 1234 request (13), timestamp reply (14), information request 1235 (15), information reply (16), address mask request (17) 1236 and address mask reply (18). 1238 There is one kind of packet that the FA MUST always discard, that is 1239 an IP fragment with a fragment offset of one. This is a valid 1240 packet, but it only has one use, to try to circumvent firewalls. 1242 An FA that is unable to interpret or apply a deny rule MUST 1243 terminate the session. An FA that is unable to interpret or apply 1244 a permit rule MAY apply a more restrictive rule. An FA MAY apply 1245 deny rules of its own before the supplied rules, for example to 1246 protect the FA owner's infrastructure. 1248 The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the 1249 ipfw.c code may provide a useful base for implementations. 1251 5.0 Key Distribution Center 1253 The mobile node and mobility agents use registration keys to compute 1254 authentication extensions applied to registration messages, as 1255 defined in [4]: Mobile-Foreign, Foreign-Home and Mobile-Home. If 1256 registration keys are requested the AAA server(s) MUST create them 1257 after the Mobile Node is successfully authenticated and authorized. 1259 If the AAAH does not communicate directly with the foreign agent, and 1260 it does not wish for intermediate proxies to have access to the 1261 session keys, they SHOULD be protected using the CMS security 1262 application [9]. 1264 The Authorization-Lifetime AVP contains the number of seconds before 1265 registration keys destined for the Home Agent and/or Foreign Agent 1266 expire. A value of zero indicates infinity (no timeout). 1268 AAA support for key distribution departs slightly from the existing 1269 SPI usage, as described in [4]. The SPI values are used as key 1270 identifiers, meaning that each registration key has its own SPI 1271 value; nodes that share a key also share an SPI. If no preferred SPI 1272 value is indicated, the AAA server MAY generate SPI values for the 1273 Mobility Agents as opposed to the receiver choosing its own SPI 1274 value. For example, suppose a Mobile Node and a Foreign Agent share a 1275 key that was generated by AAAH with a corresponding SPI value of 1276 37,496. All Mobile-Foreign Authentication extensions will be computed 1277 by either entity (in this example) using the shared key and MUST 1278 include the SPI value of 37,496. 1280 Once the registration keys have been distributed, subsequent Mobile 1281 IP registrations need not invoke the AAA infrastructure until the 1282 keys expire. These registrations MUST include the Mobile-Home 1283 authentication extension. In addition, subsequent registrations MUST 1284 also include Mobile-Foreign authentication extension if the Mobile- 1285 Foreign key was generated and distributed by AAA; similarly for 1286 subsequent use of the Foreign-Home authentication extensions. 1288 Each registration key that is generated by AAA will generally be 1289 distributed to two parties; for instance, a Mobile-Foreign key goes 1290 to both a mobile node and a foreign agent. The methods by which the 1291 key is encoded will depend upon the security associations available 1292 to the AAA server and each recipient of the key. These methods will 1293 often be different for the two recipients, so that the registration 1294 key under consideration has to be encoded twice. 1296 See sections 6.1 and 6.2 for details about the format of the AVPs 1297 used to distribute the registration keys. 1299 5.1 Distributing the Mobile-Home Registration Key 1301 If the mobile node does not have a Mobile-Home registration key, then 1302 the AAAH is likely to be the only entity trusted that is available to 1303 the mobile node. Thus, the AAAH has to generate the Mobile-Home 1304 registration key, and encode it for eventual consumption by the 1305 mobile node and home agent. 1307 If the home agent is in the home domain, then AAAH can directly 1308 encode the Mobile-Home registration key into a MIP-HA-to-MN-Key AVP 1309 and include that AVP in the HAR message for delivery to the home 1310 agent. 1312 If, on the other hand, the home agent is to be allocated in the 1313 visited domain, the AAAH does not transmit the HAR to the home agent, 1314 but instead transmits the HAR to the AAAF. When the AAAF receives the 1315 HAR, it first allocates a home agent, and then issues the HAR for 1316 that home agent. 1318 The AAAH also has to arrange for the key to be delivered to the 1319 mobile node. Unfortunately, the AAA server only knows about Diameter 1320 messages and AVPs, and the mobile node only knows about Mobile IP 1321 messages and extensions[4]. For this purpose, AAAH encodes the 1322 Mobile-Home registration key into a MIP-MN-to-HA-Key AVP, using its 1323 security association with the mobile node, which is added to the HAR 1324 message, and delivered either to a local home agent, or to the AAAF 1325 in the case where the home agent is in the visited network. The AAAH 1326 has to rely on the home agent (that also understands Diameter) to 1327 transfer the key into a Mobile IP Generalized MN-HA Key Reply 1328 extension in the Registration Reply message. The home agent can 1329 format the Reply message and extensions correctly for eventual 1330 delivery to the mobile node. The resulting Registration Reply is 1331 added to the MIP-Reg-Reply AVP and added to the AMA. 1333 After the HAA message is parsed by the AAAH, and transformed into an 1334 AMA, the AMA message containing the MIP-Reg-Reply AVP will eventually 1335 be received by the the foreign agent. The foreign agent can then use 1336 that AVP to recreate a Registration Reply message, containing the 1337 Generalized MN-HA Key Reply extension, for delivery to the mobile 1338 node. 1340 In summary, the AAAH generates the Mobile-Home registration key and 1341 encodes it into a MIP-HA-to-MN-Key AVP and a MIP-MN-to-HA-Key AVP. 1342 These AVPs are delivered to a home agent by including them in a HAR 1343 message sent from either AAAH or AAAF. The home agent decodes the key 1344 for its own use. The home agent also copies the encoded registration 1345 key from the MIP-MN-to-HA-Key AVP into a Generalized MN-HA Key Reply 1346 extension appended to the Mobile IP Registration Reply message. This 1347 Registration Reply message MUST also include the Mobile-Home 1348 authentication extension, created using the newly allocated Mobile- 1349 Home registration key. The home agent then encodes the Registration 1350 Reply message and extensions into a MIP-Reg-Reply AVP included as 1351 part of the HAA message to be sent back to the AAA server. 1353 5.2 Distributing the Mobile-Foreign Registration Key 1355 The Mobile-Foreign registration key is also generated by AAAH (upon 1356 request), so that it can be encoded into a MIP-MN-to-FA-Key AVP, 1357 which is added to the HAR, and copied by the home agent into a 1358 Generalized MN-FA Key Reply Extension [15] to the Mobile IP 1359 Registration Reply message. Most of the considerations for 1360 distributing the Mobile-Foreign registration key are similar to the 1361 distribution of the Mobile-Home Registration Key. 1363 If the MIP-FA-to-MN-Key AVP is present in the HAR, the home agent 1364 MUST ensure that the same AVP is present in the HAA. The AAAH MUST 1365 ensure that this AVP is present in the AMA, which is sent to the 1366 foreign agent. The foreign agent MUST include the FA-MN 1367 Authentication extension to the Registration Reply, using the decoded 1368 session key found in MIP-FA-to-MN-Key. 1370 5.3 Distributing the Foreign-Home Registration Key 1372 If the home agent is in the home domain, then AAAH has to generate 1373 the Foreign-Home registration key. Otherwise, it is generated by 1374 AAAF. 1376 In either case, the AAA server encodes the registration key into a 1377 MIP-HA-to-FA-Key AVP and includes that AVP as part of the HAR message 1378 sent to the home agent, and waits for the HAA message to be returned. 1380 If the MIP-FA-to-HA-Key AVP was present in the HAR, the same AVP MUST 1381 be present in the corresponding HAA, which is eventually transformed 1382 by the AAAH into an AMA message that is transmitted back to the 1383 foreign agent. 1385 Upon receipt of the HAR, the home agent recovers the Foreign-Home 1386 registration key, and uses this key to create a Foreign-Home 1387 authentication extension to the Registration Reply message. 1389 5.4 Key Distribution Example 1391 Figure 9 provides an example of subsequent Mobile IP message 1392 exchange, assuming that AAAH distributed registration keys for all 1393 three MN-FA, FA-HA and HA-MN authentication extensions. 1395 Mobile Node Foreign Agent Home Agent 1396 ----------- ------------- ---------- 1398 Reg-Req(MN-HA-Auth, MN-FA-Auth)--------> 1400 Reg-Req(MN-HA-Auth, FA-HA-Auth)--------> 1402 <--------Reg-Rep(MN-HA-Auth, FA-HA-Auth) 1404 <--------Reg-Rep(MN-HA-Auth, MN-FA-Auth) 1406 Figure 9: Mobile IP Message Exchange 1408 6.0 Key Distribution Center (KDC) AVPs 1410 The Mobile-IP protocol defines a set of security associations shared 1411 between the Mobile Node, Foreign Agent and Home Agents. These three 1412 security associations (Mobile-Home, Mobile-Foreign, and Foreign- 1413 Home), can be dynamically created by the AAAH. This requires that the 1414 AAAH create Mobile-IP Registration Keys, and that these keys be 1415 distributed to the three mobile entities, via the Diameter Protocol. 1416 AAA servers supporting the Diameter Mobile IP Application MUST 1417 implement the KDC AVPs defined in this document. In other words, AAA 1418 servers MUST be able to create three registration keys: the Mobile- 1419 Home, Mobile-Foreign, and Foreign-Home keys. 1421 The names of the KDC AVPs indicate the two entities sharing the 1422 security association defined by the encrypted key material; the 1423 intended receiver of the AVP is the first named entity. So, for 1424 instance, the MIP-MN-to-HA-Key AVP contains the Mobile-Home key 1425 encrypted in a way that allows it to be recovered by the mobile node. 1427 If strong authentication and confidentiality of the registration keys 1428 is required, it is recommended that the CMS security application [9] 1429 be used. 1431 The following table describes the Diameter AVPs defined in the Mobile 1432 IP application, their AVP Code values, types, possible flag values 1433 and whether the AVP MAY be encrypted. 1435 +---------------------+ 1436 | AVP Flag rules | 1437 |----+-----+----+-----|----+ 1438 AVP Section | | |SHLD| MUST|MAY | 1439 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 1440 -----------------------------------------|----+-----+----+-----|----| 1441 MIP-Algorithm- 345 6.2.7 Unsigned32 | M | P | | V | Y | 1442 Type | | | | | | 1443 MIP-FA-HA- 327 6.4 Unsigned32 | M | P | | V | Y | 1444 Preferred-SPI | | | | | | 1445 MIP-FA-MN- 324 6.3 Unsigned32 | M | P | | V | Y | 1446 Preferred-SPI | | | | | | 1447 MIP-FA-to-HA-Key 328 6.2.2 Grouped | M | P | | V | Y | 1448 MIP-FA-to-MN-Key 326 6.2.1 Grouped | M | P | | V | Y | 1449 MIP-HA-to-FA-Key 329 6.2.3 Grouped | M | P | | V | Y | 1450 MIP-HA-to-MN-Key 332 6.2.4 Grouped | M | P | | V | Y | 1451 MIP-MN-to-FA-Key 325 6.1.1 OctetString| M | P | | V | Y | 1452 MIP-MN-to-HA-Key 331 6.1.2 OctetString| M | P | | V | Y | 1453 MIP-Peer-SPI 342 6.2.5 Unsigned32 | M | P | | V | Y | 1454 MIP-Replay-Mode 346 6.2.8 Unsigned32 | M | P | | V | Y | 1455 MIP-Session-Key 343 6.2.6 OctetString| M | P | | V | Y | 1457 6.1 Mobile Node Registration Keys 1459 When the AAAH acts as a Key Distribution Center, and it is determined 1460 that keying material is to be created for Mobile Nodes, the AAAH 1461 creates the keys and encodes them in the MIP-MN-to-FA-Key and MIP- 1462 MN-to-HA-Key AVPs as opaque data. The actual format of the AVP value 1463 is described in [15], and would contains the data immediately 1464 following the Mobile IP extension header. 1466 The Mobile IP key described in [15] refers to the AAA SPI, which MUST 1467 be set to the value the AAAH shares with the Mobile Node. The Key 1468 Lifetime field is set to the same value as the one found in the 1469 Authorization-Lifetime AVP. 1471 6.1.1 MIP-MN-to-FA-Key AVP 1473 The MIP-MN-to-FA-Key AVP (AVP Code 325) is of type OctetString, and 1474 contains the Keying material described in the "Unsolicited MN-FA Key 1475 from AAA Subtype" in [15]. The FA SPI field of the data structure in 1476 [15] MUST be set to the same value as the MIP-Peer-SPI AVP within the 1477 FA-to-MN-Key AVP. 1479 6.1.2 MIP-MN-to-HA-Key AVP 1480 The MIP-MN-to-HA-Key AVP (AVP Code 331) is of type OctetString, and 1481 contains the Keying material described in the "Unsolicited MN-HA Key 1482 from AAA Subtype" in [15]. The HA SPI field of the data structure in 1483 [15] MUST be set to the same value as the MIP-Peer-SPI AVP within the 1484 HA-to-MN-Key AVP. 1486 6.2 Mobility Agent Session Keys 1488 The Mobility Agent session keys are the keys created by a Diameter 1489 server, which it distributes to Foreign and Home Agents, acting a 1490 Diameter clients. The lifetime of the generated keys MUST be the 1491 same as the value of the Authorization-Lifetime AVP. 1493 The MIP-Peer-SPI AVP contains the Security Parameter Index, which the 1494 Mobility Agent MUST use to refer to the Key contained in the MIP- 1495 Session-Key AVP. The Algorithm-Type AVP identifies the cryptographic 1496 function to be used in the creation of the relevant Mobile IP 1497 authentication extension. The Replay-Mode AVP specifies the replay 1498 method used in the generation of the Mobile IP registration messages. 1500 6.2.1 MIP-FA-to-MN-Key AVP 1502 The MIP-FA-to-MN-Key AVP (AVP Code 326) is of type Grouped, and 1503 contains the Foreign Agent's session key, which it shares with the 1504 Mobile Node. Its Data field has the following ABNF grammar: 1506 MIP-FA-to-MN-Key ::= < AVP Header: 326 > 1507 { MIP-Peer-SPI } 1508 { MIP-Algorithm-Type } 1509 { MIP-Session-Key } 1510 * [ AVP ] 1512 6.2.2 MIP-FA-to-HA-Key AVP 1514 The MIP-FA-to-HA-Key AVP (AVP Code 328) is of type Grouped, and 1515 contains the Foreign Agent's session key, which it shares with the 1516 Home Agent. Its Data field has the following ABNF grammar: 1518 MIP-FA-to-HA-Key ::= < AVP Header: 328 > 1519 { MIP-Peer-SPI } 1520 { MIP-Algorithm-Type } 1521 { MIP-Session-Key } 1522 * [ AVP ] 1524 6.2.3 MIP-HA-to-FA-Key AVP 1526 The MIP-HA-to-FA-Key AVP (AVP Code 329) is of type Grouped, and 1527 contains the Home Agent's session key, which it shares with the 1528 Foreign Agent. Its Data field has the following ABNF grammar: 1530 MIP-HA-to-FA-Key ::= < AVP Header: 329 > 1531 { MIP-Peer-SPI } 1532 { MIP-Algorithm-Type } 1533 { MIP-Replay-Mode } 1534 { MIP-Session-Key } 1535 * [ AVP ] 1537 6.2.4 MIP-HA-to-MN-Key AVP 1539 The MIP-HA-to-MN-Key AVP (AVP Code 332) is of type Grouped, and 1540 contains the Home Agent's session key, which it shares with the 1541 Mobile Node. Its Data field has the following ABNF grammar: 1543 MIP-HA-to-MN-Key ::= < AVP Header: 332 > 1544 { MIP-Peer-SPI } 1545 { MIP-Algorithm-Type } 1546 { MIP-Replay-Mode } 1547 { MIP-Session-Key } 1548 * [ AVP ] 1550 6.2.5 MIP-Peer-SPI AVP 1552 The MIP-Peer-SPI AVP (AVP Code 342) is of type Unsigned32, and 1553 contains the Security Parameter Index to use to reference the key in 1554 the associated MIP-Session-Key AVP. 1556 6.2.6 MIP-Session-Key AVP 1558 The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and 1559 contains the Session Key to be used between two Mobile IP entities. 1561 6.2.7 MIP-Algorithm-Type AVP 1563 The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated, and 1564 contains the Algorithm identifier used to generate the associated 1565 Mobile IP authentication extension. The following values are 1566 currently defined: 1568 0 Prefix+Suffix MD5 1569 1 HMAC-MD5 1571 6.2.8 MIP-Replay-Mode AVP 1573 The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and 1574 contains the replay mode the Home Agent should use when 1575 authenticating the Mobile Node. 1577 The following values are supported (see [4] for more information): 1579 0 None 1580 1 Timestamps 1581 2 Nonces 1583 6.3 MIP-FA-MN-Preferred-SPI AVP 1585 The MIP-FA-MN-Preferred-SPI AVP (AVP Code 324) is of type Unsigned32 1586 and is sent in the AA-Mobile-Node-Request by the Foreign Agent. The 1587 AVP contains the SPI that the Foreign Agent would prefer to have 1588 assigned by the AAAH in the MIP-FA-to-MN-Key AVP. 1590 6.4 MIP-FA-HA-Preferred-SPI AVP 1592 The MIP-FA-HA-Preferred-SPI AVP (AVP Code 327) is of type Unsigned32 1593 and is sent in the AA-Mobile-Node-Request by the Foreign Agent. The 1594 AVP contains the SPI that the Foreign Agent would prefer to have 1595 assigned by the AAAH in the MIP-FA-to-HA-Key AVP. 1597 7.0 Accounting AVPs 1599 This section will define the Accounting AVPs that are specific to 1600 Mobile IP, and MUST be included in all Accounting-Request messages. 1601 These AVPs MAY be present in the corresponding Accounting-Answer 1602 messages as well. 1604 7.1 Accounting-Input-Octets AVP 1606 The Accounting-Input-Octets AVP (AVP Code 42) is of type Unsigned64, 1607 and contains the number of octets in IP packets received from the 1608 user. 1610 7.2 Accounting-Output-Octets AVP 1612 The Accounting-Output-Octets AVP (AVP Code 43) is of type Unsigned64, 1613 and contains the number of octets in IP packets sent to the user. 1615 7.3 Accounting-Session-Time AVP 1617 The Accounting-Session-Time AVP (AVP Code 46) is of type Unsigned32, 1618 and indicates the length of the current session in seconds. 1620 7.4 Accounting-Input-Packets AVP 1622 The Accounting-Input-Packets (AVP Code 47) is of type Unsigned64, and 1623 contains the number of IP packets received from the user. 1625 7.5 Accounting-Output-Packets AVP 1627 The Accounting-Output-Packets (AVP Code 48) is of type Unsigned64, 1628 and contains the number of IP packets sent to the user. 1630 8.0 AVP Occurrence Tables 1632 The following tables presents the AVPs defined in this document, and 1633 specifies in which Diameter messages they MAY, or MAY NOT be present. 1634 Note that AVPs that can only be present within a Grouped AVP are not 1635 represented in this table. 1637 The table uses the following symbols: 1638 0 The AVP MUST NOT be present in the message. 1639 0+ Zero or more instances of the AVP MAY be present in the 1640 message. 1641 0-1 Zero or one instance of the AVP MAY be present in the 1642 message. 1643 1 One instance of the AVP MUST be present in the message. 1645 8.1 Mobile IP Command AVP Table 1647 The table in this section is limited to the Command Codes defined in 1648 this specification. 1650 +-----------------------+ 1651 | Command-Code | 1652 |-----+-----+-----+-----+ 1653 Attribute Name | AMR | AMA | HAR | HAA | 1654 ------------------------------|-----+-----+-----+-----+ 1655 Authorization-Lifetime | 0-1 | 1 | 1 | 1 | 1656 Destination-Host | 0-1 | 1 | 0-1 | 1 | 1657 Destination-Realm | 1 | 0 | 1 | 0 | 1658 Error-Reporting-Host | 0 | 0-1 | 0 | 0-1 | 1659 Auth-Application-Id | 1 | 1 | 1 | 1 | 1660 Filter-Rule | 0 | 0+ | 0+ | 0 | 1661 MIP-FA-Challenge | 0-1 | 0 | 0 | 0 | 1662 MIP-FA-to-HA-Key | 0 | 0-1 | 0-1 | 0-1 | 1663 MIP-FA-to-MN-Key | 0 | 0-1 | 0-1 | 0-1 | 1664 MIP-FA-HA-Preferred-SPI | 0-1 | 0 | 0 | 0 | 1665 MIP-FA-MN-Preferred-SPI | 0-1 | 0 | 0 | 0 | 1666 MIP-Feature-Vector | 0-1 | 0 | 0 | 0 | 1667 MIP-Foreign-Agent-Host | 0 | 0 | 1 | 1 | 1668 MIP-HA-to-FA-Key | 0 | 0 | 0-1 | 0 | 1669 MIP-HA-to-MN-Key | 0 | 0 | 0-1 | 0 | 1670 MIP-Home-Agent-Address | 0-1 | 0-1 | 0-1 | 0-1 | 1671 MIP-MN-AAA-Auth | 1 | 0 | 0 | 0 | 1672 MIP-MN-to-FA-Key | 0 | 0 | 0-1 | 0 | 1673 MIP-MN-to-HA-Key | 0 | 0-1 | 0-1 | 0 | 1674 MIP-Mobile-Node-Address | 0-1 | 0-1 | 0-1 | 0-1 | 1675 MIP-Previous-FA-Address | 0-1 | 0 | 0 | 0 | 1676 MIP-Previous-FA-Host | 0-1 | 0 | 0 | 0 | 1677 MIP-Reg-Reply | 0 | 0-1 | 0 | 0-1 | 1678 MIP-Reg-Request | 1 | 0 | 1 | 0 | 1679 Origin-Host | 1 | 1 | 1 | 1 | 1680 Origin-Realm | 1 | 1 | 1 | 1 | 1681 Original-State-Id | 0-1 | 0-1 | 0-1 | 0-1 | 1682 Proxy-Info | 0+ | 0+ | 0+ | 0+ | 1683 Result-Code | 0 | 1 | 0 | 1 | 1684 Route-Record | 0+ | 0+ | 0+ | 0+ | 1685 Session-Id | 1 | 1 | 1 | 1 | 1686 Session-Timeout | 0 | 1 | 1 | 1 | 1687 User-Name | 1 | 0 | 1 | 0 | 1688 ------------------------------|-----+-----+-----+-----| 1690 8.2 Accounting AVP Table 1691 The table in this section is used to represent which AVPs defined in 1692 this document are to be present in the Accounting messages, defined 1693 in [1]. 1695 +-------------+ 1696 | Command-Code| 1697 |------+------+ 1698 Attribute Name | ACR | ACA | 1699 ------------------------------|------+------+ 1700 Accounting-Input-Octets | 1 | 0-1 | 1701 Accounting-Input-Packets | 1 | 0-1 | 1702 Accounting-Output-Octets | 1 | 0-1 | 1703 Accounting-Output-Packets | 1 | 0-1 | 1704 Accounting-Session-Time | 1 | 0-1 | 1705 MIP-Feature-Vector | 1 | 0-1 | 1706 MIP-Home-Agent-Address | 1 | 0-1 | 1707 MIP-Mobile-Node-Address | 1 | 0-1 | 1708 MIP-Previous-FA-Address | 0-1 | 0-1 | 1709 MIP-Previous-FA-Host | 0-1 | 0-1 | 1710 ------------------------------|------+------+ 1712 9.0 Acknowledgements 1714 The following people have contributed text to this document: Fredrik 1715 Johansson, Martin Julien 1717 The authors would like to thank Nenad Trifunovic, Haseeb Akhtar and 1718 Pankaj Patel for their participation in the Document Reading Party, 1719 to Erik Guttman for his very useful proposed text, and to Tony 1720 Johansson for the proposed text AND being in the doc reading party. 1721 The authors would also like to thank the participants of 3GPP2's 1722 TSG-P working group for their valuable feedback. 1724 10.0 IANA Considerations 1726 This section contains the namespaces that have either been created in 1727 this specification, or the values assigned to existing namespaces 1728 managed by IANA. 1730 10.1 Command Codes 1732 This specification assigns the values 260 and 262 from the Command 1733 Code namespace defined in [1]. See section 2.0 for the assignment of 1734 the namespace in this specification. 1736 10.2 AVP Codes 1738 This specification assigns the values 320-322, 324-346 from the AVP 1739 Code namespace defined in [1]. See sections 4.0 and 6.0 for the 1740 assignment of the namespace in this specification. 1742 This specification also makes use of AVP Code 400, which is assigned 1743 in [14]. 1745 10.3 Result-Code AVP Values 1747 This specification assigns the values 4004-4007, and 5018 from the 1748 Result-Code AVP (AVP Code 268) value namespace defined in [1]. See 1749 section 3.0 for the assignment of the namespace in this 1750 specification. 1752 10.4 DSI-Event AVP Values 1754 This specification assigns the values 4002-4003 and 5009 from the 1755 DSI-Event AVP (AVP Code 297) value namespace defined in [1]. See 1756 section 4.0 for the assignment of the namespace in this 1757 specification. 1759 10.5 MIP-Feature-Vector AVP Values 1761 There are 32 bits in the MIP-Feature-Vector AVP (AVP Code 337) that 1762 are available for assignment. This document assigns bits 1-9, as 1763 listed in section 4.7. The remaining bits should only be assigned via 1764 Standards Action [2]. 1766 10.6 MIP-Algorithm-Type AVP Values 1768 As defined in Section 6.2.7, the MIP-Algorithm-Type AVP (AVP Code 1769 345) defines the values 0-1. All remaining values are available for 1770 assignment via Designated Expert [2]. 1772 10.7 MIP-Replay-Mode AVP Values 1774 As defined in Section 6.2.8, the MIP-Replay-Mode AVP (AVP Code 346) 1775 defines the values 0-2. All remaining values are available for 1776 assignment via Designated Expert [2]. 1778 10.8 Application Identifier 1780 This specification assigns the value four (4) to the Application 1781 Identifier namespace defined in [1]. See section 1.7 for more 1782 information. 1784 11.0 Security Considerations 1786 This specification describes the Diameter Application necessary to 1787 authenticate and authorize a Mobile IP Mobile Node. The 1788 authentication algorithm used is dependent upon the transforms 1789 available by the Mobile IP protocol, and [5]. This specification also 1790 defines a method by which the home Diameter server can create and 1791 distribute registration keys to be used to authenticate Mobile IP 1792 registration messages. The keys SHOULD be be protected using the 1793 methods defined in [9]. 1795 12.0 References 1797 [1] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens, "Diame- 1798 ter Base Protocol", draft-ietf-aaa-diameter-05.txt, IETF work in 1799 progress, June 2001. 1801 [2] Narten, Alvestrand,"Guidelines for Writing an IANA Considera- 1802 tions Section in RFCs", BCP 26, RFC 2434, October 1998 1804 [3] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, 1805 Authorization, and Accounting Requirements". RFC 2977. October 1806 2000. 1808 [4] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. 1810 [5] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response Exten- 1811 sions". RFC 3012. November 2000. 1813 [6] B. Aboba, M. Beadles "The Network Access Identifier." RFC 2486. 1814 January 1999. 1816 [7] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", 1817 RFC 2477, January 1999. 1819 [8] P. Calhoun, C. Perkins, "Mobile IP Network Address Identifier 1820 Extension", RFC 2794, March 2000. 1822 [9] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security 1823 Application", draft-ietf-aaa-diameter-cms-sec-00.txt, IETF work 1824 in progress, June 2001. 1826 [10] Kent, Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 1827 2406, November 1998. 1829 [11] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1830 Levels", BCP 14, RFC 2119, March 1997. 1832 [12] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 1833 2279, January 1998. 1835 [13] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing 1836 for Message Authentication. RFC 2104, February 1997. 1838 [14] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASREQ 1839 Application", draft-ietf-aaa-diameter-nasreq-05.txt, IETF work 1840 in progress, June 2001. 1842 [15] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile IP", 1843 draft-ietf-mobileip-aaa-key-05.txt, IETF work in progress, May 1844 2001. 1846 [16] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA", 1847 draft-hiller-cdma2000-aaa-01.txt, IETF work in progress, June 1848 2000. 1850 13.0 Authors' Addresses 1852 Questions about this memo can be directed to: 1854 Pat R. Calhoun 1855 Network and Security Research Center, Sun Labs 1856 Sun Microsystems, Inc. 1857 15 Network Circle 1858 Menlo Park, California, 94025 1859 USA 1861 Phone: +1 650-786-7733 1862 Fax: +1 650-786-6445 1863 E-mail: pcalhoun@eng.sun.com 1864 Charles E. Perkins 1865 Nokia Research Center 1866 313 Fairchild Drive 1867 Mountain View, California 94043 1868 USA 1870 Phone: +1 650-625-2986 1871 Fax: +1 650-625-2502 1872 E-Mail: charliep@iprg.nokia.com 1874 14.0 Full Copyright Statement 1876 Copyright (C) The Internet Society (2001). All Rights Reserved. 1878 This document and translations of it may be copied and furnished to 1879 others, and derivative works that comment on or otherwise explain it 1880 or assist in its implementation may be prepared, copied, published 1881 and distributed, in whole or in part, without restriction of any 1882 kind, provided that the above copyright notice and this paragraph are 1883 included on all such copies and derivative works. However, this docu- 1884 ment itself may not be modified in any way, such as by removing the 1885 copyright notice or references to the Internet Society or other 1886 Internet organizations, except as needed for the purpose of develop- 1887 ing Internet standards in which case the procedures for copyrights 1888 defined in the Internet Standards process must be followed, or as 1889 required to translate it into languages other than English. The lim- 1890 ited permissions granted above are perpetual and will not be revoked 1891 by the Internet Society or its successors or assigns. This document 1892 and the information contained herein is provided on an "AS IS" basis 1893 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 1894 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 1895 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1896 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1897 FITNESS FOR A PARTICULAR PURPOSE. 1899 15.0 Expiration Date 1901 This memo is filed as and 1902 expires in December 2001.