idnits 2.17.1 draft-ietf-aaa-diameter-mobileip-11.txt: -(1918): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1921): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1992): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1995): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1998): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2002): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 10 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 48 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 49 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 18 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A home AAA server (AAAH) and foreign AAA server (AAAF), which support the Mobile-IP authentication application MAY maintain session-state or MAY be session-stateless. AAA redirect agents and AAA relay agents MUST not maintain session-state. The AAAH, AAAF, proxies and relays agents MUST maintain transaction state. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The following tables presents the AVPs defined in this document, and specifies in which Diameter messages they MAY, or MAY NOT be present. Note that AVPs that can only be present within a Grouped AVP are not represented in this table. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2002) is 7979 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) == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-11 ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3220 (ref. 'MOBILEIP') (Obsoleted by RFC 3344) ** Obsolete normative reference: RFC 3012 (ref. 'MIPCHAL') (Obsoleted by RFC 4721) ** Obsolete normative reference: RFC 2486 (ref. 'NAI') (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-aaa-key-09 -- Possible downref: Normative reference to a draft: ref. 'MIPKEYS' -- No information found for draft-mobileip-aaa-nai - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'AAANAI' -- Unexpected draft version: The latest known version of draft-ietf-aaa-diameter-cms-sec is -04, but you're referring to -05. (However, the state information for draft-mobileip-aaa-nai is not up-to-date. The last update was unsuccessful) -- Obsolete informational reference (is this intentional?): RFC 1750 (ref. 'RANDOM') (Obsoleted by RFC 4086) Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AAA Working Group Pat R. Calhoun 3 Internet-Draft Black Storm Networks 4 Category: Standards Track Tony Johansson 5 Ericsson Inc 6 Charles E. Perkins 7 Nokia Research Center 8 June 2002 10 Diameter Mobile IPv4 Application 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC 2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Distribution of this memo is unlimited. 35 Copyright (C) The Internet Society 2002. All Rights Reserved. 37 Abstract 39 This document specifies a Diameter application that allows a Diameter 40 server to authenticate, authorize and collect accounting information 41 for Mobile IPv4 services rendered to a mobile node. Combined with 42 the Inter-Realm capability of the base protocol, this application 43 allows mobile nodes to receive service from foreign service 44 providers. Diameter Accounting messages will be used by the foreign 45 and home agents to transfer usage information to the Diameter 46 servers. 48 Table of Contents 50 1.0 Introduction 51 1.1 Requirements language 52 1.2 Inter-Realm Mobile IP 53 1.3 Support for Mobile IP Handoffs 54 1.4 Allocation of Home Agent in Foreign Network 55 1.5 Co-located Mobile Node 56 1.6 Diameter Session Termination 57 1.7 Advertising Application support 58 1.8 Fast Handoff support 59 2.0 Command-Code Values 60 2.1 AA-Mobile-Node-Request 61 2.2 AA-Mobile-Node-Answer 62 2.3 Home-Agent-MIP-Request 63 2.4 Home-Agent-MIP-Answer 64 3.0 Result-Code AVP Values 65 3.1 Transient Failures 66 3.2 Permanent Failures 67 4.0 Diameter AVPs 68 4.1 MIP-Reg-Request AVP 69 4.2 MIP-Reg-Reply AVP 70 4.3 MIP-Mobile-Node-Address AVP 71 4.4 MIP-Home-Agent-Address AVP 72 4.5 MIP-Feature-Vector AVP 73 4.6 MIP-MN-AAA-Auth AVP 74 4.6.1 MIP-MN-AAA-SPI AVP 75 4.6.2 MIP-Auth-Input-Data-Length AVP 76 4.6.3 MIP-Authenticator-Length AVP 77 4.6.4 MIP-Authenticator-Offset AVP 78 4.7 MIP-FA-Challenge AVP 79 4.8 MIP-Filter-Rule AVP 80 4.9 MIP-Candidate-Home-Agent-Host 81 4.10 MIP-Originating-Foreign-AAA AVP 82 4.11 MIP-Home-Agent-Host AVP 83 5.0 Key Distribution Center 84 5.1 Authorization Lifetime vs. MIP Key Lifetime 85 5.2 Key Material vs. Session Key 86 5.3 Distributing the Mobile-Home Session Key 87 5.4 Distributing the Mobile-Foreign Session Key 88 5.5 Distributing the Foreign-Home Session Key 89 5.6 Key Distribution Example 90 6.0 Key Distribution Center (KDC) AVPs 91 6.1 MIP-FA-to-MN-Key AVP 92 6.2 MIP-FA-to-HA-Key AVP 93 6.3 MIP-HA-to-FA-Key AVP 94 6.4 MIP-HA-to-MN-Key AVP 95 6.5 MIP-MN-to-FA-Key AVP 96 6.6 MIP-MN-to-HA-Key AVP 97 6.7 MIP-Session-Key AVP 98 6.8 MIP-Algorithm-Type AVP 99 6.9 MIP-Replay-Mode AVP 100 6.10 MIP-FA-to-MN-SPI 101 6.11 MIP-FA-to-HA-SPI 102 6.12 MIP-Key-Material AVP 103 6.13 MIP-Key-Lifetime AVP 104 7.0 Accounting AVPs 105 7.1 Accounting-Input-Octets AVP 106 7.2 Accounting-Output-Octets AVP 107 7.3 Acct-Session-Time AVP 108 7.4 Accounting-Input-Packets AVP 109 7.5 Accounting-Output-Packets AVP 110 7.6 Event-Timestamp AVP 111 8.0 AVP Table 112 8.1 Mobile IP Command AVP Table 113 8.2 Accounting AVP Table 114 9.0 IANA Considerations 115 9.1 Command Codes 116 9.2 AVP Codes 117 9.3 Result-Code AVP Values 118 9.4 MIP-Feature-Vector AVP Values 119 9.5 MIP-Algorithm-Type AVP Values 120 9.6 MIP-Replay-Mode AVP Values 121 9.7 Application Identifier 122 10.0 Security Considerations 123 11.0 References 124 11.1 Normative 125 11.2 Informative 126 12.0 Acknowledgements 127 13.0 Authors' Addresses 128 14.0 Full Copyright Statement 129 15.0 Expiration Date 131 1.0 Introduction 133 Mobile IP, as defined in [MOBILEIP], defines a method that allows a 134 mobile node to change its point of attachment to the Internet with 135 minimal service disruption. Mobile IP does not provide any specific 136 support for mobility across disparate administrative domains, and 137 therefore does not specify how usage can be accounted for, which has 138 limited the applicability of Mobile IP in a IPv4 commercial 139 deployment. The Mobile IP specification as defined in [MOBILEIP] 140 recommends mobile nodes to have a static home address and a home 141 agent. However this may not be always possible in certain deployment 142 scenarios. Recent developments in areas that impact IP mobility in 143 the IETF allow Mobile IP [MOBILEIP] to work just as well when mobile 144 nodes do not have a static home agent and home address. In addition, 145 another specification [MIPNAI] allows a mobile node to use its NAI 146 instead of its home address, which better accommodates current 147 administrative practice. 149 This document specifies an Application of 4 to the Diameter base 150 protocol [DIAMBASE] that allows a Diameter server to authenticate, 151 authorize and collect accounting information for Mobile IPv4 services 152 rendered to a mobile node. This application MUST NOT be used in 153 conjunction with the Mobile IPv6 protocol. 155 Combined with the Inter-Realm capability of the base protocol, this 156 application allows mobile nodes to receive service from foreign 157 service providers. The Diameter Accounting messages will be used by 158 the foreign and home agents to transfer usage information to the 159 Diameter servers. 161 The Mobile IP protocol [MOBILEIP] specifies a security model that 162 requires that mobile nodes and home agents share a pre-existing 163 security association, which leads to scaling and configuration 164 issues. This specification defines Diameter functions that allow the 165 AAA server to act as a Key Distribution Center (KDC), whereby dynamic 166 session keys are created and distributed to the mobility entities for 167 the purposes of securing Mobile IP Registration messages. 169 Strong authentication and confidentiality of session keys is 170 required, and it is recommended to be provided using the CMS security 171 application [CMS], but may be provided via other security mechanisms, 172 e.g. using mutually authenticated TLS or IPsec when deployed in an 173 environment without Diameter agents, then hop-by-hop security is 174 sufficient for protecting session keys. (It should be noted that the 175 CMS security application is referenced as informative in this 176 application and the usage is only a recommendation.) However, if a 177 home AAA server is explicitly configured to need the CMS security 178 application for this domain/transaction then it will not proceed 179 without it, that is, the requested service MUST fail if CMS isn't 180 available. 182 As with the Diameter base protocol, AAA servers implementing the 183 Mobile IP application can process users' identities supplied in a 184 Network Access Identifier (NAI) format [NAI], which is used for 185 Diameter message routing purposes. Mobile nodes include their NAI in 186 Registration messages, as defined in [MIPNAI]. The use of the NAI is 187 consistent with the roaming model defined by the ROAMOPS Working 188 Group [EVALROAM]. 190 A home AAA server (AAAH) and foreign AAA server (AAAF), which support 191 the Mobile-IP authentication application MAY maintain session-state 192 or MAY be session-stateless. AAA redirect agents and AAA relay agents 193 MUST not maintain session-state. The AAAH, AAAF, proxies and relays 194 agents MUST maintain transaction state. 196 Given the nature of Mobile IP, a re-authentication can only be 197 initiated by a mobile node, which does not participate in the 198 Diameter message exchanges. Therefore Diameter server initiated re- 199 auth does not apply to this application. 201 Furthermore, the nature of mobile IP also means that the mobile node 202 will do handoffs between different foreign agents. To guarantee that 203 a registered user always ends up in the same initial AAAH, the mobile 204 node SHOULD always include the AAAH NAI [AAANAI]. Finally, to assist 205 the AAAH in routing the messages to a mobile node's home agent the 206 mobile node SHOULD always include the HA NAI [AAANAI]. If the mobile 207 node does not support the Mobile IP AAA NAI extension [AAANAI], this 208 MAY limit the functionality that can be offered to such a mobile 209 node. 211 The Diameter Mobile-IP Application meets the requirements specified 212 in [MIPREQ, CDMA2000]. Later subsections in this introductory section 213 provide some examples and message flows of the Mobile IP and Diameter 214 messages that occur when a mobile node requests service in a foreign 215 network. In this document, the role of the "attendant" [MIPREQ] is 216 performed by either the home agents (for co-located mobile nodes) or 217 foreign agents for the Mobile-IP Application, and these terms will be 218 used interchangeably. 220 1.1 Requirements language 222 In this document, the key words "MAY", "MUST", "MUST NOT", 223 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 224 interpreted as described in [KEYWORDS]. 226 1.2 Inter-Realm Mobile IP 228 When a mobile node requests service by issuing a Registration Request 229 to the foreign agent, the foreign agent creates the AA-Mobile-Node- 230 Request (AMR) message, which includes the AVPs defined in section 231 2.1. The Home Address, Home Agent, Mobile Node NAI and other 232 important fields are extracted from the registration messages for 233 possible inclusion as Diameter AVPs. The AMR message is then 234 forwarded to the local Diameter server, known as the AAA-Foreign, or 235 AAAF. 237 Visited Realm Home Realm 238 +--------+ +--------+ 239 |abc.com | AMR/AMA |xyz.com | 240 | AAAF |<------------------->| AAAH | 241 +->| server | server-server | server | 242 | +--------+ communication +--------+ 243 | ^ ^ 244 | AMR/AMA | client-server | HAR/HAA 246 | | communication | 247 v v v 248 +---------+ +---------+ +---------+ 249 | Foreign | | Foreign | | Home | 250 | Agent | | Agent | | Agent | 251 +---------+ +---------+ +---------+ 252 ^ 253 | Mobile IP 254 | 255 v 256 +--------+ 257 | Mobile | 258 | Node | mn@xyz.com 259 +--------+ 260 Figure 1: Inter-Realm Mobility 262 Upon receiving the AMR, the AAAF follows the procedures outlined in 264 [DIAMBASE] to determine whether the AMR should be processed locally, 265 or if it should be forwarded to another Diameter server, known as the 266 AAA-Home, or AAAH. Figure 1 shows an example in which a mobile node 267 (mn@xyz.com) requests service from a foreign provider (abc.com). The 268 request received by the AAAF is forwarded to xyz.com's AAAH server. 270 Figure 2 shows the message flows involved when the foreign agent 271 invokes the AAA infrastructure to request that a mobile node be 272 authenticated and authorized. Note that it is not required that the 273 foreign agent invoke AAA services every time a Registration Request 274 is received from the mobile, but rather only when the prior 275 authorization from the AAAH expires. The expiration time of the 276 authorization is communicated through the Authorization-Lifetime AVP 277 in the AA-Mobile-Node-Answer (AMA, see section 2.2) from the AAAH. 279 Mobile Node Foreign Agent AAAF AAAH Home Agent 280 ----------- ------------- ------------ ---------- ---------- 281 Advertisement & 282 <--------- Challenge 284 Reg-Req&MN-AAA ----> 286 AMR------------> 287 Session-Id = foo 289 AMR------------> 290 Session-Id = foo 292 HAR-----------> 293 Session-Id = bar 295 <----------HAA 296 Session-Id = bar 298 <-----------AMA 299 Session-Id = foo 301 <------------AMA 302 Session-Id = foo 304 <-------Reg-Reply 306 Figure 2: Mobile IP/Diameter Message Exchange 308 The foreign agent (as shown in Figure 2) MAY provide a challenge, 309 which gives it direct control over the replay protection in the 310 Mobile IP registration process, as described in [MIPCHAL]. The 311 mobile node includes the Challenge and MN-AAA authentication 312 extension to enable authorization by AAAH. If the authentication data 313 supplied in the MN-AAA extension is invalid, AAAH returns the 314 response (AMA) with the Result-Code AVP set to 315 DIAMETER_AUTHENTICATION_REJECTED. 317 A mobile node with AAA NAI extension support [AAANAI], which has been 318 previously authenticated and authorized, MUST always include the 319 assigned home agent in the HA Identity subtype of the AAA NAI 320 extension, and the authorizing Home AAA server in the AAAH Identity 321 subtype of the AAA NAI extension, when re-authenticating. So, in the 322 event that the AMR generated by the FA is for a session that was 323 previously authorized, it MUST include the Destination-Host AVP, with 324 the identity of the AAAH found in the AAAH-NAI, and the MIP-Home- 325 Agent- Host AVP with the identity and realm of the assigned HA found 326 in the HA-NAI. If on the other hand the mobile node does not support 327 the AAA NAI extension, the FA may not have the identity of the AAAH 328 and the identity and realm of the assigned HA. This means that 329 without support of the AAA NAI extension, the FA may not be able to 330 guarantee, that the AMR well be destined to the same AAAH, which 331 previously authenticated and authorized the mobile node, since the FA 332 may not know the identity of the AAAH. 334 If the mobile node was successfully authenticated, the AAAH checks if 335 the home agent was located in the foreign realm, by checking Home- 336 Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. Other 337 AVP's like the MIP-Home-Agent-Host AVP and the MIP-Originating- 338 Foreign-AAA AVP may also be used to verify the location of the home 339 agent. If the home agent is located in the foreign realm, then the 340 AAAH sends an HAR message to the home agent, which contains a MIP- 341 Reg-Request AVP. 343 If the home agent was not located in the foreign realm, the AAAH 344 checks for the MIP-Home-Agent-Address AVP and if present the MIP- 345 Home-Agent-Host AVP. If one was specified, the AAAH checks that the 346 address is that of a known home agent and that the mobile node is 347 allowed to request this particular home agent, and that the home 348 agent's identity is included in the MIP-Home-Agent-Host AVP. If no 349 home agent was specified, and if the MIP-Feature-Vector has the Home- 350 Agent-Requested flag set, and if allowed by policy in the home realm, 351 the AAAH SHOULD allocate a home agent on behalf of the mobile node. 352 This can be done in a variety of ways, including using a load 353 balancing algorithm in order to keep the load on all home agents 354 equal. The actual algorithm used and the method of discovering the 355 home agents is outside the scope of this specification. 357 The AAAH then sends an Home-Agent-MIP-Request (HAR), which contains 358 the Mobile IP Registration Request message data encapsulated in the 359 MIP-Reg-Request AVP, to the assigned or requested Home Agent. The 360 AAAH MAY allocate a home address for the mobile node, while the Home 361 Agent MUST support home address allocation. In the event the AAAH 362 handles address allocation, it includes it in a MIP-Mobile-Node- 363 Address AVP within the HAR. The absence of this AVP informs the Home 364 Agent to perform the allocation. 366 During the creation of the HAR, the AAAH MUST use a different session 367 identifier than the one used in the AMR/AMA (see Figure 2). If the 368 AAAH is session-stateful, it MUST send the same session identifier 369 for all HARs initiated on behalf of a given mobile node's session. 370 Otherwise, if the AAAH is session-stateless, it will manufacture a 371 unique session-id for every HAR. 373 A mobile node's session is identified via its identity in the User- 374 Name AVP, the MIP-Mobile-Node-Address and the MIP-Home-Agent-Address 375 AVPs. This is necessary in order to allow the session state machine, 376 defined in the base protocol [DIAMBASE], to be used unmodified with 377 this application. Therefore, an STR from a foreign agent would free 378 the session from the foreign agent, but not the one towards the home 379 agent (see figure 3). 381 STR, Session-Id = foo STR, Session-Id = bar 382 ---------------------> <-------------------- 383 +----+ +------+ +------+ +----+ 384 | FA | | AAAF | | AAAH | | HA | 385 +----+ +------+ +------+ +----+ 386 <--------------------- ---------------------> 387 STA, Session-Id = foo STA, Session-Id = bar 388 Figure 3: Session Termination and Session Identifiers 390 Upon receipt of the HAR, the home agent first processes the Diameter 391 message. The home agent processes the MIP-Reg-Request AVP and creates 392 the Registration Reply, encapsulating it within the MIP-Reg-Reply 393 AVP. In the creation of the Registration Reply the Home Agent must 394 include the HA NAI and the AAAH NAI, which will be created from the 395 Origin-Host AVP and Origin-Realm AVP of the HAR. If a home address is 396 needed, the home agent MUST also assign one and include the address 397 in both the Registration Reply and within the MIP-Mobile-Node-Address 398 AVP. 400 The HA MUST include an Acct-Multi-Session-Id AVP in the HAA returned 401 to the AAAH. 403 Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer 404 (AMA) message, includes the Acct-Multi-Session-Id that was present in 405 the HAA, and the MIP-Home-Agent-Address, MIP-Mobile-Node-Address AVPs 406 in the AMA message, enabling appropriate firewall controls for the 407 penetration of tunneled traffic between the home agent and the mobile 408 node. 410 1.3 Support for Mobile IP Handoffs 412 Given the nature of Mobile IP, a mobile node MAY receive service from 413 many foreign agents during a period of time. However, the home realm 414 should not view these handoffs as different sessions, since this 415 could affect billing systems. Furthermore, many foreign agents do not 416 communicate, which makes it quite difficult for AAA information to be 417 exchanged between these entities. Therefore, it MUST be assumed that 418 a foreign agent is not aware that a registration request from a 419 mobile node has been previously authorized. 421 A handoff registration request from a mobile node will cause an AMR 422 to be sent to its AAAF. The AMR will include a new session 423 identifier, and MAY be sent to an AAAF in the visited network other 424 than the AAAF, which received the previous AMR. However, with the 425 usage of the AAA NAI, this AMR is guaranteed to be received by the 426 AAAH to which the user is currently registered. 428 Since the AAAH may be session-stateless, it is necessary for the 429 resulting HAR received by the HA to be identified as a continuation 430 of an existing session. If the HA receives an HAR for a mobile node, 431 with a new session identifier, and the HA can guarantee that this 432 request is to extend service for an existing service, then the HA 433 MUST be able to modify its internal session state information to 434 reflect the new session identifier. 436 It is necessary for accounting records to have some commonality 437 across handoffs in order for correlation to occur. Therefore, the 438 home agent MUST send the same Acct-Multi-Session-Id AVP value in all 439 HAAs for the mobile's session. That is, the HA generates a unique 440 Acct-Multi-Session-Id when receiving an HAR for a new session, and 441 returns this same value in every HAA for the session. This Acct- 442 Multi-Session-Id AVP will be returned to the foreign agent by the 443 AAAH in the AMA. Both the foreign and home agents MUST include the 444 Acct-Multi-Session-Id in the accounting messages. 446 ACR, Session-Id = foo ACR, Session-Id = bar 447 Acct-Multi-Session-Id = a Acct-Multi-Session-Id = a 448 ---------------------> <-------------------- 449 +----+ +------+ +------+ +----+ 450 | FA | | AAAF | | AAAH | | HA | 451 +----+ +------+ +------+ +----+ 452 <--------------------- ---------------------> 453 ACA, Session-Id = foo ACA, Session-Id = bar 455 Figure 4: Accounting messages w/ Mobile IP Application 457 1.4 Allocation of Home Agent in Foreign Network 459 The Diameter Mobile IP application allows a home agent to be 460 allocated in a foreign network, as required in [MIPREQ, CDMA2000]. 461 When a foreign agent detects that the mobile node has a home agent 462 address equal to 0.0.0.0 or 255.255.255.255 in the Registration 463 Request message, it MUST add a MIP-Feature-Vector AVP with the Home- 464 Agent- Requested flag set to one. If the home agent address is equal 465 to 255.255.255.255, then the foreign agent also MUST set the Home- 466 Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home 467 agent address is set to 0.0.0.0, the foreign agent MUST set the Home- 468 Address-Allocatable-Only-in-Home-Realm flag equal to zero. 470 When the AAAF receives an AMR message with the Home-Agent-Requested 471 flag set to one, and the Home-Address-Allocatable-Only-in-Home-Realm 472 flag equal to zero, the AAAF MAY set the Foreign-Home-Agent-Available 473 flag in the MIP-Feature-Vector AVP to inform the AAAH that it is 474 willing and able to assign a Home Agent for the mobile node. When 475 doing so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host AVP 476 and the MIP-Originating-Foreign-AAA-AVP. The MIP-Candidate-Home- 477 Agent-Host AVP contains the identity of the home agent that would be 478 assigned to the mobile node and the MIP-Originating-Foreign-AAA AVP 479 contains the identity of the AAAF. 481 In the event that the mobile node with AAA NAI extension support 482 [AAANAI] has been previously authorized by the AAAH and now needs to 483 be re-authenticated, and requests to keep the assigned home agent in 484 the foreign network, the mobile node MUST include the HA NAI and the 485 AAAH NAI in the registration request to the FA. Upon receipt, the FA 486 will create the AMR including the MIP-Home-Agent-Address AVP, the 487 Destination-Host AVP based on the AAAH NAI and include the MIP-Home- 488 Agent-Host AVP based on the home agent NAI. If the AAAF authorizes 489 the use of the requested home agent, the AAAF MUST set the Home- 490 Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. 492 In the event that the mobile node that does not support the AAA NAI 493 extension has been previously authorized by the AAAH and now needs to 494 be re-authenticated, and requests to keep the assigned home agent in 495 the foreign network, the mobile node sends a registration request 496 without the AAA NAI and the HA NAI. Upon receipt, the FA will create 497 the AMR including the MIP-Home-Agent-Address AVP. If the AAAF 498 authorizes the use of the requested home agent, and if it has 499 knowledge that the requested home agent is in its own domain, the 500 AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP- 501 Feature-Vector AVP. 503 When the AAAH receives an AMR message, it first checks the 504 authentication data supplied by the mobile node, according to the 505 MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether 506 to authorize the mobile node. If the AMR indicates that the AAAF has 507 offered to allocate a Home Agent for the mobile node, i.e. the 508 Foreign-Home-Agent-Available is set in the MIP-Feature-Vector AVP, or 509 the AMR indicates that the AAAF has offered a previously allocated 510 Home Agent for the mobile node, i.e. the Home-Agent-In-Foreign- 511 Network is set in the MIP-Feature-Vector AVP, then the AAAH must 512 decide whether its local policy would allow the user to have a Home 513 Agent in the foreign network or to keep the Home Agent in the foreign 514 network. If so, and after checking authorization from the data in the 515 AMR message, the AAAH sends the HAR message to Home Agent by 516 including the Destination-Host AVP set to the value found in the 517 AMR's MIP-Candidate-Home-Agent-Host AVP or MIP-Home-Agent-Host AVP if 518 the HA has been previously allocated and authorized by the AAAH. If 519 the HA has not been previously allocated by the foreign domain, the 520 HAR sent by the AAAH does not contain the MIP-Home-Agent-Address. 522 If the AAAH's local policy determines that the MN-HA Key and/or the 523 MN-FA Key must be encrypted, the AAAH sends the HAR to the 524 originating AAAF. In this HAR the Destination-Host AVP is set to the 525 value found in the AMR's MIP-Originating-Foreign-AAA AVP, and the 526 MIP-Home-Agent-Host AVP or the MIP-Candidate-Home-Agent-Host AVP 527 found in the AMR are copied into the HAR. If no security association 528 exists between the AAAH and the originating AAAF, the AAAH will make 529 use of the CMS application [CMS] to establish this association. 530 However, if no security association cannot be established the AAAH 531 MUST return an AMA with the Result-Code AVP set to 532 DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION. 534 If the AAAH's local policy determines that no keys need to be 535 encrypted, the HAR is sent by the AAAH back to the foreign realm with 536 the Destination-Host AVP set to the home agent's identity. This HAR 537 may not necessarily be received by the same AAAF, which sent the AMR. 538 Therefore the AAAH MUST always copy the MIP-Originating-Foreign-AAA 539 AVP from the AMR message to the HAR message. In cases when another 540 AAAF receives the HAR, this new AAAF will use the MIP-Originating- 541 Foreign-AAA AVP for policy decisions, such as determining if the FA- 542 HA Key should be encrypted or not. 544 Visited Home 545 Realm Realm 546 +--------+ ------- AMR -------> +--------+ 547 | AAAF | <------ HAR -------- | AAAH | 548 | | | | 549 +--->| server | ------- HAA -------> | server | 550 | +--------+ <------ AMA -------- +--------+ 551 | ^ | 552 | | | 553 HAR/HAA | AMR | | AMA 554 v | v 555 +---------+ +---------+ 556 | Home | | Foreign | 557 | Agent | | Agent | 558 +---------+ +---------+ 559 ^ 560 +--------+ | 561 | Mobile |<----------+ 562 | Node | Mobile IP 563 +--------+ 564 Figure 5: Home Agent allocated in Visited Realm 566 Upon receipt of a HAA from the Home Agent in the visited realm, the 567 AAAF forwards the HAA to the AAAH in the home realm. The AMA is then 568 constructed, and issued to the AAAF, and finally to the FA. If the 569 Result-Code indicates success, the HAA and AMA MUST include the MIP- 570 Home-Agent-Address and the MIP-Mobile-Node-Address AVPs. 572 Mobile Node Foreign Agent Home Agent AAAF AAAH 573 ----------- ------------- ------------- ---------- ---------- 575 <----Challenge---- 576 Reg-Req (Response)-> 577 ------------AMR-------------> 578 -----AMR----> 579 <----HAR----- 580 <-----HAR------ 581 ------HAA------> 582 -----HAA----> 583 <----AMA----- 584 <-------------AMA------------ 585 <---Reg-Reply---- 586 Figure 6: Mobile IP/Diameter Message Exchange 588 If the mobile node moves to another foreign Network, it MAY either 589 request to keep the same Home Agent within the old foreign network, 590 or request to get a new one in the new foreign network. If the AAAH 591 is willing to provide the requested service, the mobile node will 592 have to be serviced by two AAAFs. 594 Figure 7 shows the message flows for a mobile node requesting to keep 595 the home agent assigned in foreign network 1 when it moves to foreign 596 network 2. Upon reception of the AMR in foreign network 2, the AAAF 597 follows the procedures described earlier and forwards AMR to the 598 mobile node's home network, i.e. its AAAH. If the mobile node was 599 successfully authenticated, the AAAH checks the identity of the 600 foreign and home agent to determine whether the user is in a third 601 realm. If this is the case, the AAAH must check whether the mobile is 602 still permitted to use the previously assigned home agent. 604 +---------------+ +---------------+ +-------------+ 605 |Foreign net 2 | |Foreign net 1 | |Home network | 606 | | | | | | 607 Mobile Node | FA AAAF | | HA AAAF | | AAAH | 608 ----------- | ---- ---- | | ---- ------ | | ------ | 609 +---------------+ +---------------+ +-------------+ 611 <----Challenge---- 612 Reg-Req (Response)-> 613 ---AMR---> 614 ----------------AMR---------------> 615 <-----HAR----- 616 <---HAR---- 617 ----HAA---> 618 ------HAA----> 619 <---------------AMA---------------- 620 <--AMA---- 621 <----Reg-Reply----- 622 Figure 7: Request to access Home Agent from new foreign network 624 If the mobile node is allowed to keep the home agent the AAAH then 625 sends a HAR, which contains the Mobile IP Registration Request 626 message data encapsulated in the MIP-Reg-Request AVP and the MIP- 627 Home-Agent-Address AVP with home agent address, as well as any 628 optional KDC session keys, to the AAAF in foreign network 1. 629 Furthermore, the AAAH MUST always copy MIP-Originating-Foreign-AAA 630 AVP from AMR and include it in the HAR when a third foreign domain is 631 involved, since the AAAF will use the MIP-Originating-Foreign-AAA AVP 632 for policy decisions, such as determining if the FA-HA Key should be 633 encrypted or not. Upon reception the AAAF in foreign network 1 will 634 forward the HAR to the Home Agent if its local policy allows such 635 service. If the AAAF does not permit such service, it MUST return a 636 DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. 638 If the AAAH local policy determines that the MN-HA Key must be 639 encrypted and no security association is known to the home agent, the 640 AAAH MUST send the HAR to the AAAF in foreign network 1, which 641 originally assigned the HA in foreign network 1, by including its 642 identity in the Destination-Host AVP. 644 When the AAAF receives a HAA, the AAAF will forward the HAA back to 645 the AAAH. If successful, the HAA MUST include the MIP-Home-Agent- 646 Address and the MIP-Mobile-Node-Address AVPs. The AAAH will then send 647 back an AMA to the AAAF in foreign network 2. 649 If the old foreign network does not permit the use of its Home Agent 650 when the mobile node moves to a new foreign network, the AAAH or AAAF 651 MUST return an AMA with the Result-Code AVP set to 652 DIAMETER_ERROR_HA_NOT_AVAILABLE. Upon receipt of this error, the 653 foreign agent MUST issue a Mobile IP Registration Reply to the mobile 654 node with an appropriate error. The mobile node MAY attempt to 655 request that a new Home Agent and Address be allocated. When the AAAH 656 transmits such an error, it MUST issue a Diameter Abort-Session- 657 Request message to the Home Agent to enable it to release any 658 resources. 660 1.5 Co-located Mobile Node 662 In the event that a mobile node registers with the Home Agent as a 663 co-located mobile node, there is no foreign agent involved. 664 Therefore, when the Home Agent receives the Registration Request, an 665 AMR message is sent to the local AAAH server, with the Co-Located- 666 Mobile-Node bit set in the MIP-Feature-Vector AVP. The Home Agent 667 also includes the Acct-Multi-Session-Id AVP in the AMR sent to the 668 AAAH, as the AAAH may find this a useful piece of session-state or 669 log entry information. 671 Home 672 Realm 673 +--------+ 674 | AAAH | 675 | | 676 | server | 677 +--------+ 678 ^ | 679 | | 680 AMR | | AMA 681 | v 682 +--------+ +---------+ 683 | Mobile | Registration | Home | 684 | Node |-------------->| Agent | 685 +--------+ Request +---------+ 686 Figure 8: Co-located Mobile Node 688 If the MN-HA-Key-Requested bit was set in the AMR message from the 689 Home Agent, the home agent and mobile node's session keys would be 690 present in the AMA message. 692 1.6 Diameter Session Termination 694 A foreign and home agent following this specification MAY expect 695 their respective Diameter servers to maintain session state 696 information for each mobile node in their networks. In order for the 697 Diameter Server to release any resources allocated to a specific 698 mobile node, the mobility agents MUST send a Session-Termination- 699 Request (STR) to the Diameter server that authorized the service. The 700 Session-Termination-Request (STR) MUST be issued by the mobility 701 agents if the Authorization Lifetime has expired and no subsequent 702 MIP registration request have been received. 704 The Home Diameter server SHOULD only deallocate all resources after 705 the STR is received from the home agent. This ensures that a mobile 706 node that moves from one foreign agent to another (hand-off) does not 707 cause the Home Diameter Server to free all resources for the mobile 708 node. 710 In the event that the AAAF wishes to terminate a session, its Abort- 711 Session-Request (ASR) [DIAMBASE] message SHOULD be sent to the FA. 712 Similarly, the AAAH SHOULD send its message to the Home Agent. 714 1.7 Advertising application support 716 Diameter nodes conforming to this specification MAY advertise support 717 by including the value of four (4) in the Auth-Application-Id or the 718 Acct-Application-Id AVP of the Capabilities-Exchange-Request and 719 Capabilities-Exchange-Answer command [DIAMBASE]. 721 1.8 Fast Handoff support 723 This application requires that foreign agents issue an AMR upon 724 receipt of the first registration message from a mobile node, 725 regardless of the fact that the mobile node MAY have been previously 726 authorized to another foreign agent. 728 The Mobile IP Working Group is currently investigating fast handoff 729 proposals, and the Seamoby WG is looking at creating a protocol that 730 would allow AAA state information to be exchange between foreign 731 agents during a handoff. These proposals MAY allow future 732 enhancements to the Diameter protocol, in order to reduce the amount 733 of Diameter exchanges required during a handoff. 735 2.0 Command-Code Values 737 This section defines Command-Code [DIAMBASE] values that MUST be 738 supported by all Diameter implementations conforming to this 739 specification. The following Command Codes are defined in this 740 specification: 742 Command-Name Abbreviation Code Section 743 ----------------------------------------------------------- 744 AA-Mobile-Node-Answer AMA 260 2.2 745 AA-Mobile-Node-Request AMR 260 2.1 746 Home-Agent-MIP-Answer HAA 262 2.4 747 Home-Agent-MIP-Request HAR 262 2.3 749 2.1 AA-Mobile-Node-Request 751 The AA-Mobile-Node-Request (AMR), indicated by the Command-Code field 752 set to 260 and the 'R' bit set in the Command Flags field, is sent by 753 an attendant, acting as a Diameter client, to a server in order to 754 request the authentication and authorization of a mobile node. The 755 foreign agent (or home agent in the case of a co-located Mobile Node) 756 uses information found in the Registration Request to construct the 757 following AVPs that are to be included as part of the AMR: 759 home address (MIP-Mobile-Node-Address AVP) 760 home agent address (MIP-Home-Agent-Address AVP) 761 mobile node NAI (User-Name AVP [DIAMBASE]) 762 MN-HA Key Request (MIP-Feature-Vector AVP) 763 MN-FA Key Request (MIP-Feature-Vector AVP) 764 MN-AAA Authentication Extension (MIP-MN-AAA-Auth AVP) 765 foreign agent Challenge Extension (MIP-FA-Challenge AVP) 766 home agent NAI (MIP-Home-Agent-Host AVP) 767 home AAA server NAI (Destination-Host AVP [DIAMBASE]) 769 If the mobile node's home address is zero, the foreign or home agent 770 MUST NOT include a MIP-Mobile-Node-Address AVP in the AMR. If the 771 home agent address is zero or all ones, the MIP-Home-Agent-Address 772 AVP MUST NOT be present in the AMR. 774 If a foreign agent is used in a visited network, the AAAF MAY set the 775 Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP in 776 the AMR message to indicate that it is willing to assign a Home Agent 777 in the visited realm. 779 If the mobile node's home address is all ones, the foreign or home 780 agent MUST include a MIP-Mobile-Node-Address AVP, set to all ones. 782 If the mobile node includes the home agent NAI and the home AAA 783 server NAI [AAANAI], the foreign agent MUST include the MIP-Home- 784 Agent-Host AVP and the Destination-Host AVP in the AMR. 786 Message Format 788 ::= < Diameter Header: 260, REQ, PXY > 789 < Session-ID > 790 { Auth-Application-Id } 791 { User-Name } 792 { Destination-Realm } 793 { Origin-Host } 794 { Origin-Realm } 795 { MIP-Reg-Request } 796 { MIP-MN-AAA-Auth } 797 [ Acct-Multi-Session-Id ] 798 [ Destination-Host ] 799 [ Origin-State-Id ] 800 [ MIP-Mobile-Node-Address ] 801 [ MIP-Home-Agent-Address ] 802 [ MIP-Feature-Vector ] 803 [ MIP-Originating-Foreign-AAA ] 804 [ Authorization-Lifetime ] 805 [ Auth-Session-State ] 806 [ MIP-FA-Challenge ] 807 [ MIP-Candidate-Home-Agent-Host ] 808 * [ Proxy-Info ] 809 * [ Route-Record ] 810 * [ AVP ] 812 2.2 AA-Mobile-Node-Answer 814 The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code field 815 set to 260 and the 'R' bit cleared in the Command Flags field, is 816 sent by the AAAH in response to the AA-Mobile-Node-Request message. 817 The User-Name MAY be included in the AMA if present in the AMR. The 818 Result-Code AVP MAY contain one of the values defined in section 3.0, 819 in addition to the values defined in [DIAMBASE]. 821 An AMA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST 822 include the MIP-Home-Agent-Address AVP, MUST include the MIP-Mobile- 823 Node-Address AVP, and includes the MIP-Reg-Reply AVP if and only if 824 the Co-Located-Mobile-Node bit was not set in the MIP-Feature-Vector 825 AVP. The MIP-Home-Agent-Address AVP contains the Home Agent assigned 826 to the mobile node, while the MIP-Mobile-Node-Address AVP contains 827 the home address that was assigned. The AMA message MUST contain the 828 MIP-FA-to-HA-Key, MIP-FA-to-MN-Key if they were requested in the AMR, 829 and they were present in the HAR. The MIP-MN-to-HA-Key and MIP-HA-to- 830 MN-Key AVPs MUST be present if the session keys were requested in the 831 AMR, and the Co-Located-Mobile-Node bit was set in the MIP-Feature- 832 Vector AVP. 834 An AMA message with the Result-Code AVP set to 835 DIAMETER_LIMITED_SUCCESS MAY include the MIP-Home-Agent-Address AVP 836 if a dynamically assigned home agent was requested by the mobile 837 node. Upon receipt of this result code, the foreign agent MUST issue 838 the Registration Request to the Home Agent in the manner described in 839 [MOBILEIP]. 841 An AMA message with the Result-Code set to DIAMETER_MULTI_ROUND_AUTH 842 MAY include mobile node session key AVPs (see Section 6.1) such as 843 the MIP-MN-to-FA-Key AVP and the MIP-MN-to-HA-Key AVP. If such an AVP 844 is present in the AMA message, the foreign agent MUST include the 845 corresponding Mobile IP key distribution extension in the 846 Registration Reply it sends to the mobile node. This is to support 847 multi-roundtrip authentication mechanisms. 849 Message Format 851 ::= < Diameter Header: 260, PXY > 852 < Session-Id > 853 { Auth-Application-Id } 854 { Result-Code } 855 { Origin-Host } 856 { Origin-Realm } 857 [ Acct-Multi-Session-Id ] 858 [ User-Name ] 859 [ Authorization-Lifetime ] 860 [ Auth-Session-State ] 861 [ Error-Message ] 862 [ Error-Reporting-Host ] 863 [ Re-Auth-Request-Type ] 864 [ MIP-Feature-Vector ] 865 [ MIP-Reg-Reply ] 866 [ MIP-MN-to-FA-Key ] 867 [ MIP-MN-to-HA-Key ] 868 [ MIP-FA-to-MN-Key ] 869 [ MIP-FA-to-HA-Key ] 870 [ MIP-HA-to-MN-Key ] 871 [ MIP-HA-to-FA-Key ] 872 [ MIP-Key-Lifetime ] 873 [ MIP-Home-Agent-Address ] 874 [ MIP-Mobile-Node-Address ] 875 * [ MIP-Filter-Rule ] 876 [ Origin-State-Id ] 877 * [ Proxy-Info ] 878 * [ AVP ] 880 2.3 Home-Agent-MIP-Request 882 The Home-Agent-MIP-Request (HAR), indicated by the Command-Code field 883 set to 262 and the 'R' bit set in the Command Flags field, is sent by 884 the AAA to the Home Agent. If the Home Agent is to be assigned in a 885 foreign network, the HAR is issued by the AAAH and forwarded by the 886 AAAF. If the HAR message does not include a MIP-Mobile-Node-Address 887 AVP, and the Registration Request has 0.0.0.0 for the home address, 888 and the HAR is successfully processed, the Home Agent MUST allocate 889 one such address to the mobile node. If the home agent's local AAA 890 server allocates the mobile node's home address, it MUST include the 891 assigned address in an MIP-Mobile-Node-Address AVP. 893 When session keys are requested for use by the mobile node (see 894 section 5.0), the AAAH MUST create them and include them in the HAR 895 message. When a Foreign-Home session key is requested, it will be 896 created and distributed by the AAA server in the same realm as the 897 home agent. 899 Message Format 901 ::= < Diameter Header: 262, REQ, PXY > 902 < Session-Id > 903 { Auth-Application-Id } 904 { Authorization-Lifetime } 905 { Auth-Session-State } 906 { MIP-Reg-Request } 907 { Origin-Host } 908 { Origin-Realm } 909 { User-Name } 910 { Destination-Realm } 911 { MIP-Feature-Vector } 912 [ Destination-Host ] 913 [ MIP-MN-to-HA-Key ] 914 [ MIP-MN-to-FA-Key ] 915 [ MIP-HA-to-MN-Key ] 916 [ MIP-HA-to-FA-Key ] 917 [ MIP-Key-Lifetime ] 918 [ MIP-Originating-Foreign-AAA ] 919 [ MIP-Mobile-Node-Address ] 920 [ MIP-Home-Agent-Address ] 921 * [ MIP-Filter-Rule ] 922 [ Origin-State-Id ] 923 * [ Proxy-Info ] 924 * [ Route-Record ] 925 * [ AVP ] 927 2.4 Home-Agent-MIP-Answer 929 The Home-Agent-MIP-Answer (HAA), indicated by the Command-Code field 930 set to 262 and the 'R' bit cleared in the Command Flags field, is 931 sent by the Home Agent to its local AAA server in response to a Home- 932 Agent-MIP-Request. The User-Name MAY be included in the HAA if 933 present in the HAR. If the home agent allocated a home address for 934 the mobile node, the address MUST be included in the MIP-Mobile-Node- 935 Address AVP. The Result-Code AVP MAY contain one of the values 936 defined in section 3.0 instead of the values defined in [DIAMBASE]. 938 Message Format 940 ::= < Diameter Header: 262, PXY > 941 < Session-Id > 942 { Auth-Application-Id } 943 { Result-Code } 944 { Origin-Host } 945 { Origin-Realm } 946 [ Acct-Multi-Session-Id ] 947 [ User-Name ] 948 [ Error-Reporting-Host ] 949 [ Error-Message ] 950 [ MIP-Reg-Reply ] 951 [ MIP-Home-Agent-Address ] 952 [ MIP-Mobile-Node-Address ] 953 [ MIP-FA-to-HA-SPI ] 954 [ MIP-FA-to-MN-SPI ] 955 [ Origin-State-Id ] 956 * [ Proxy-Info ] 957 * [ AVP ] 959 3.0 Result-Code AVP Values 961 This section defines new Result-Code [DIAMBASE] values that MUST be 962 supported by all Diameter implementations that conform to this 963 specification. 965 3.1 Transient Failures 967 Errors that fall within the transient failures category are used to 968 inform a peer that the request could not be satisfied at the time it 969 was received, but MAY be able to satisfy the request in the future. 971 DIAMETER_ERROR_MIP_REPLY_FAILURE 4005 972 This error code is used by the Home Agent when processing of 973 the Registration Request has failed. 975 DIAMETER_ERROR_HA_NOT_AVAILABLE 4006 976 This error code is used to inform the foreign agent that the 977 requested Home Agent cannot be assigned to the mobile node at 978 this time. The foreign agent MUST return a Mobile IP 979 Registration Reply to the mobile node with an appropriate error 980 code. 982 DIAMETER_ERROR_BAD_KEY 4007 983 This error code is used by the Home Agent to indicate to the 984 local Diameter server that the key generated is invalid. 986 3.2 Permanent Failures 988 Errors that fall within the permanent failures category are used to 989 inform the peer that the request failed, and should not be attempted 990 again. 992 DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE 5024 993 This error is used by the AAAF to inform the AAAH that 994 allocation of a home agent in the foreign domain is not 995 permitted at this time. 997 DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION 5025 998 This error is used by the AAAF / AAAH to inform that the 999 requested mobile IP session keys could not be encrypted with 1000 the CMS strong security application and therefore failed. 1002 4.0 Mandatory AVPs 1004 The following table describes the Diameter AVPs defined in the Mobile 1005 IP application, their AVP Code values, types, possible flag values 1006 and whether the AVP MAY be encrypted. 1008 Due to space constraints, the short form IPFiltrRule is used to 1009 represent IPFilterRule and DiamIdent is used to represent 1010 DiameterIdentity. 1012 +---------------------+ 1013 | AVP Flag rules | 1014 |----+-----+----+-----|----+ 1015 AVP Section | | |SHLD| MUST|MAY | 1016 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 1017 -----------------------------------------|----+-----+----+-----|----| 1018 MIP-Filter-Rule 342 4.8 IPFiltrRule| M | P | | V | Y | 1019 MIP-Auth-Input- 338 4.6.2 Unsigned32 | M | P | | V | Y | 1020 Data-Length | | | | | | 1021 MIP- 339 4.6.3 Unsigned32 | M | P | | V | Y | 1022 Authenticator-Length | | | | | | 1023 MIP- 340 4.6.4 Unsigned32 | M | P | | V | Y | 1024 Authenticator-Offset | | | | | | 1025 MIP-Candidate- 336 4.9 DiamIdent | M | P | | V | N | 1026 Home-Agent-Host | | | | | | 1027 MIP-Home-Agent- 348 4.11 DiamIdent | M | P | | V | N | 1028 Host | | | | | | 1029 MIP-FA-Challenge 344 4.7 OctetString| M | P | | V | Y | 1030 MIP-Feature- 337 4.5 Unsigned32 | M | P | | V | Y | 1031 Vector | | | | | | 1032 MIP-Home-Agent- 334 4.4 IPAddress | M | P | | V | Y | 1033 Address | | | | | | 1034 MIP-MN-AAA-Auth 322 4.6 Grouped | M | P | | V | Y | 1035 MIP-MN-AAA-SPI 341 4.6.1 Unsigned32 | M | P | | V | Y | 1036 MIP-Mobile-Node- 333 4.3 IPAddress | M | P | | V | Y | 1037 Address | | | | | | 1038 MIP-Reg-Request 320 4.1 OctetString| M | P | | V | Y | 1039 MIP-Reg-Reply 321 4.2 OctetString| M | P | | V | Y | 1040 MIP-Originating- 347 4.10 Grouped | M | P | | V | Y | 1041 Foreign-AAA | | | | | | 1043 4.1 MIP-Reg-Request AVP 1045 The MIP-Reg-Request AVP (AVP Code 320) is of type OctetString and 1046 contains the Mobile IP Registration Request [MOBILEIP] sent by the 1047 mobile node to the foreign agent. 1049 4.2 MIP-Reg-Reply AVP 1051 The MIP-Reg-Reply AVP (AVP Code 321) is of type OctetString and 1052 contains the Mobile IP Registration Reply [MOBILEIP] sent by the home 1053 agent to the foreign agent. 1055 4.3 MIP-Mobile-Node-Address AVP 1057 The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type IPAddress 1058 and contains the mobile node's home address. 1060 4.4 MIP-Home-Agent-Address AVP 1062 The MIP-Home-Agent-Addess AVP (AVP Code 334) is of type IPAddress and 1063 contains the mobile node's home agent address. 1065 4.5 MIP-Feature-Vector AVP 1067 The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and 1068 is added with flag values set by the foreign agent or by the AAAF 1069 owned by the same administrative domain as the foreign agent. The 1070 foreign agent SHOULD include MIP-Feature-Vector AVP within the AMR 1071 message it sends to the AAAF. 1073 Flag values currently defined include: 1074 1 Mobile-Node-Home-Address-Requested 1075 2 Home-Address-Allocatable-Only-in-Home-Realm 1076 4 Home-Agent-Requested 1077 8 Foreign-Home-Agent-Available 1078 16 MN-HA-Key-Request 1079 32 MN-FA-Key-Request 1080 64 FA-HA-Key-Request 1081 128 Home-Agent-In-Foreign-Network 1082 256 Co-Located-Mobile-Node 1084 The flags are set according to the following rules. 1086 If the mobile node includes a valid home address (i.e., not equal to 1087 0.0.0.0 or 255.255.255.255) in its Registration Request, the foreign 1088 agent zeroes the Mobile-Node-Home-Address-Requested flag in the MIP- 1089 Feature-Vector AVP. 1091 If the mobile node sets the home address field equal to 0.0.0.0 in 1092 its Registration Request, the foreign agent sets the Mobile-Node- 1093 Home-Address-Requested flag to one. 1095 If the mobile node sets the home agent field equal to 255.255.255.255 1096 in its Registration Request, the foreign agent sets both the Home- 1097 Agent-Requested flag and the Home-Address-Allocatable-Only-in-Home- 1098 Realm flag to one in the MIP-Feature-Vector AVP. 1100 If the mobile node sets the home agent field equal to 0.0.0.0 in its 1101 Registration Request, the foreign agent sets the Home-Agent-Requested 1102 flag to one, and zeroes the Home-Address-Allocatable-Only-in-Home- 1103 Realm flag in the MIP-Feature-Vector AVP. 1105 Whenever the foreign agent sets either the Mobile-Node-Home-Address- 1106 Requested flag or the Home-Agent-Requested flag to one, it MUST set 1107 the MN-HA-Key-Request flag to one. The MN-HA-Key-Request flag is also 1108 set to one if the mobile node includes a Generalized MN-HA Key 1109 Request [MIPKEYS] extension, with the subtype set to AAA. 1111 If the mobile node includes a Generalized MN-FA Key Request [MIPKEYS] 1112 extension with the AAA subtype in its Registration Request, the 1113 foreign agent sets the MN-FA-Key-Request flag to one in the MIP- 1114 Feature-Vector AVP. 1116 If the mobile node requests a home agent in the foreign network 1117 either by setting the home address field to all ones, or by 1118 specifying a home agent in the foreign network, and the AAAF 1119 authorizes the request, the AAAF MUST set the Home-Agent-In-Foreign- 1120 Network bit to one. 1122 If the Home Agent receives a Registration Request from the mobile 1123 node indicating that the MN is acting as a co-located mobile node, 1124 the home agent sets the Co-Located-Mobile-Node bit to one. 1126 If the foreign agent's local policy allows it to receive AAA session 1127 keys, and it does not have any existing FA-HA key with the home 1128 agent, the foreign agent MAY set the FA-HA-Key-Request flag 1130 The foreign agent MUST NOT set the Foreign-Home-Agent-Available, and 1131 Home-Agent-In-Foreign-Network flag to one. 1133 When the AAAF receives the AMR message, it MUST first verify that the 1134 sender was an authorized foreign agent. The AAAF then takes any 1135 actions indicated by the settings of the MIP-Feature-Vector AVP 1136 flags. The AAAF then MAY set additional flags.Only the AAAF may set 1137 the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network 1138 flags to one. This is done according to local administrative policy. 1139 When the AAAF has finished setting additional flags according to its 1140 local policy, then the AAAF transmits the AMR with the possibly 1141 modified MIP-Feature-Vector AVP to the AAAH. 1143 4.6 MIP-MN-AAA-Auth AVP 1145 The MN-AAA-Auth AVP (AVP Code 322) is of type Grouped and contains 1146 some ancillary data to simplify processing of the authentication data 1147 in the Mobile IP Registration Request [MOBILEIP] by the target AAA 1148 server. Its value has the following ABNF grammar: 1150 MIP-MN-AAA-Auth ::= < AVP Header: 322 > 1151 { MIP-MN-AAA-SPI } 1152 { MIP-Auth-Input-Data-Length } 1153 { MIP-Authenticator-Length } 1154 { MIP-Authenticator-Offset } 1155 * [ AVP ] 1157 4.6.1 MIP-MN-AAA-SPI AVP 1158 The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and 1159 indicates the algorithm by which the targeted AAA server (AAAH) 1160 should attempt to validate the Authenticator computed by the mobile 1161 node over the Registration Request data. 1163 4.6.2 MIP-Auth-Input-Data-Length AVP 1165 The MIP-Auth-Input-Data-Length AVP (AVP Code 338) is of type 1166 Unsigned32 and contains the length, in bytes, of the Registration 1167 Request data (data portion of MIP-Reg-Request AVP) that should be 1168 used as input to the algorithm (indicated by the MN-AAA-SPI AVP) used 1169 to determine whether the Authenticator Data supplied by the mobile 1170 node is valid. 1172 4.6.3 MIP-Authenticator-Length AVP 1174 The MIP-Authenticator-Length AVP (AVP Code 339) is of type Unsigned32 1175 and contains the length of the authenticator to be validated by the 1176 targeted AAA server (i.e., AAAH). 1178 4.6.4 MIP-Authenticator-Offset AVP 1180 The MIP-Authenticator-Offset AVP (AVP Code 340) is of type Unsigned32 1181 and contains the offset into the Registration Request Data, of the 1182 authenticator to be validated by the targeted AAA server (i.e., 1183 AAAH). 1185 4.7 MIP-FA-Challenge 1187 The MIP-FA-Challenge AVP (AVP Code 344) is of type OctetString and 1188 contains the challenge advertised by the foreign agent to the mobile 1189 node. This AVP MUST be present in the AMR if the mobile node used the 1190 RADIUS-style MN-AAA computation algorithm. 1192 4.8 MIP-Filter-Rule AVP 1194 The MIP-Filter-Rule AVP (AVP Code 342) is of type IPFilterRule, and 1195 provides filter rules that need to be configured on the foreign or 1196 home Agent for the user. One or more such AVPs MAY be present in an 1197 authorization response. 1199 4.9 MIP-Candidate-Home-Agent-Host 1201 The MIP-Candidate-Home-Agent-Host AVP (AVP Code 336) is of type 1202 DiameterIdentity and contains the identity of a home agent in the 1203 foreign network that the AAAF proposes be dynamically assigned to the 1204 mobile node. 1206 4.10 MIP-Originating-Foreign-AAA AVP 1208 The MIP-Originating-Foreign-AAA AVP (AVP Code 347) if of type 1209 Grouped, and contains the identity of the AAAF, which issues the AMR 1210 to the AAAH. The MIP- Originating-Foreign-AAA AVP MUST only be used 1211 in cases when the home agent is or may be allocated in a foreign 1212 domain. If present in the AMR, the AAAH MUST copy the MIP- 1213 Originating-Foreign-AAA AVP into the HAR. 1215 MIP-Originating-Foreign-AAA ::= < AVP Header: 347 > 1216 { Origin-Realm } 1217 { Origin-Host } 1218 * [ AVP ] 1220 4.11 MIP-Home-Agent-Host AVP 1222 The MIP-Home-Agent-Host AVP (AVP Code 348) if of type Grouped, and 1223 contains the identity of the assigned Home Agent. If present in the 1224 AMR, the AAAH MUST copy the MIP-Home-Agent-Host AVP into the HAR. 1226 MIP-Home-Agent-Host ::= < AVP Header: 348 > 1227 { Destination-Realm } 1228 { Destination-Host } 1229 * [ AVP ] 1231 5.0 Key Distribution Center 1233 The mobile node and mobility agents use session keys to compute 1234 authentication extensions applied to registration messages, as 1235 defined in [MOBILEIP]: Mobile-Foreign, Foreign-Home and Mobile-Home. 1236 If session keys are requested the AAA server(s) MUST return the key 1237 material after the mobile node is successfully authenticated and 1238 authorized. 1240 The SPI values are used as key identifiers, meaning that each session 1241 key has its own SPI value; nodes that share a key also share an SPI. 1242 The mobile node proposes SPIs for use in computing the Mobile-Foreign 1243 and Mobile-Home authentication extensions, via the Mobile IP AAA Key 1244 Request extensions [MIPKEYS], while the home agent allocates the 1245 Mobile-Foreign, Mobile-Home and Foreign-Home SPIs. 1247 Once the session keys have been distributed, subsequent Mobile IP 1248 registrations need not invoke the AAA infrastructure until the keys 1249 expire. These registrations MUST include the Mobile-Home 1250 authentication extension. In addition, subsequent registrations MUST 1251 also include Mobile-Foreign authentication extension if the Mobile- 1252 Foreign key was generated and distributed by AAA; similarly for 1253 subsequent use of the Foreign-Home authentication extensions. 1255 5.1 Authorization Lifetime vs. MIP Key Lifetime 1257 The Diameter Mobile IP application makes use of two timers - the 1258 Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP. 1260 The Authorization-Lifetime contains the number of seconds before the 1261 mobile node must issue a subsequent MIP registration request. The 1262 content of the Authorization-Lifetime AVP corresponds to the Lifetime 1263 field in the MIP header [MOBILEIP]. 1265 The MIP-Key-Lifetime AVP contains the number of seconds before 1266 session keys destined for the mobility agents and the mobile node 1267 expire. A value of zero indicates infinity (no timeout). If not zero, 1268 the value of the MIP-Key-Lifetime AVP MUST be at least equal to the 1269 value in the Authorization Lifetime AVP. 1271 5.2 Key Material vs. Session Key 1273 Each session key that is generated by the AAAH will generally be 1274 distributed to two parties; for instance, a Mobile-Foreign is sent to 1275 both the mobile node and the foreign agent. 1277 The key sent to the mobile node is always in the form of key 1278 material, which the AAAH does by generating a random [RANDOM] value 1279 of at least 64 bits. The random value is used by the mobile node to 1280 create the actual session key. The following is an example of a 1281 session creation procedure, using MD5 as the hashing algorithm. 1282 Additional algorithms are supported, and listed in [MIPKEYS]. 1284 MD5(AAA-Key | key material | node-address | AAA-Key) 1286 Where: 1288 - AAA-Key is the long term secret shared between the mobile 1289 node and the AAAH. 1290 - Key material is a random [RANDOM] value of at least 64 bits. 1291 - node-address is the mobile node's identity. This is the 1292 contents of the MIP-Mobile-Node-Address AVP, unless the value 1293 of the AVP is all zero or ones, in which case of value of the 1294 User-Name AVP is used instead. 1296 The AAAH then generates the session key, which is destined for the 1297 mobility agent, in this case the foreign agent, by following the 1298 above procedures. It is important that the hashing algorithm used by 1299 the mobile node to construct the session key is the same as the one 1300 used by the AAAH in the session key generation procedure. The AAAH 1301 therefore indicates the algorithm used along with the key material. 1302 The session keys destined for mobility agents may be encoded using 1303 the security association available between the AAA server and the 1304 agents (e.g. IPSec, TLS, CMS). 1306 The Foreign-Home session key is shared between two mobility agents: 1307 the FA and HA. Since this key is not destined for the mobile node, 1308 there is no need to follow the session key generation procedures 1309 detailed above. Instead, the AAAH generates a random [RANDOM] value 1310 of at least 64 bits for use as the Foreign-Home session key. 1312 See sections 6.0 for details about the format of the AVPs used to 1313 transport the session keys. 1315 5.3 Distributing the Mobile-Home Session Key 1317 If the mobile node does not have a Mobile-Home session key, then the 1318 AAAH is likely to be the only entity trusted that is available to the 1319 mobile node. Thus, the AAAH has to generate the Mobile-Home session 1320 key, and encode it for eventual consumption by the mobile node and 1321 home agent. 1323 If the home agent is in the home realm, then the AAAH can directly 1324 encode the Mobile-Home session key into a MIP-HA-to-MN-Key AVP and 1325 include that AVP in the HAR message for delivery to the home agent. 1327 If, on the other hand, the home agent is to be allocated in the 1328 visited realm, the AAAH transmits the HAR to the foreign home agent, 1329 where, prior to delivery to the home agent, it is perused by the AAAF 1330 hosting the home agent. If the session key needs to be encrypted the 1331 AAAH will encrypt the MIP-HA-to-MN Key AVP and the MIP-FA-to-MN AVP 1332 with help of CMS security application [CMS] using the security 1333 association with the AAAF associated with the home agent. If no 1334 security association exists between the AAAH and the AAAF associated 1335 with the home agent, the AAAH will check if a security association 1336 can be established. If no security association exists and cannot be 1337 created, the AAAH MUST return a Result-Code AVP with 1338 DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION. 1340 The AAAH also has to arrange for the key to be delivered to the 1341 mobile node. Unfortunately, the AAA server only knows about Diameter 1342 messages and AVPs, and the mobile node only knows about Mobile IP 1343 messages and extensions [MOBILEIP]. For this purpose, AAAH encodes 1344 the Mobile-Home session key material into a MIP-MN-to-HA-Key AVP, 1345 using its security association with the mobile node, which is added 1346 to the HAR message, and delivered either to a local home agent, or to 1347 the AAAF in the case where the home agent is in the visited network. 1348 The AAAH has to rely on the home agent (that also understands 1349 Diameter) to transfer the keying information into a Mobile IP 1350 Generalized MN-HA Key Reply extension [MIPKEYS] in the Registration 1351 Reply message, using the SPI proposed by the Mobile Node in the MN-HA 1352 Key Request From AAA Subtype extension. The home agent can format the 1353 Reply message and extensions correctly for eventual delivery to the 1354 mobile node. The resulting Registration Reply is added to the HAA's 1355 MIP-Reg-Reply AVP. 1357 After the HAA message is parsed by the AAAH, and transformed into an 1358 AMA, the AMA message containing the MIP-Reg-Reply AVP will eventually 1359 be received by the the foreign agent. The foreign agent can then use 1360 that AVP to recreate a Registration Reply message, containing the 1361 Generalized MN-HA Key Reply extension, for delivery to the mobile 1362 node. 1364 In summary, the AAAH generates the Mobile-Home key material, which is 1365 added to the MIP-MN-to-HA-Key AVP. The key material is then used to 1366 compute the home agent's session key as specified in [MIPKEYS], which 1367 is then added to the MIP-HA-to-MN-Key AVP. These AVPs are delivered 1368 to a home agent by including them in a HAR message sent from either 1369 AAAH or AAAF. The home agent decodes the key for its own use. The 1370 home agent also copies the encoded key material from the MIP-MN-to- 1371 HA-Key AVP into a Generalized MN-HA Key Reply extension appended to 1372 the Mobile IP Registration Reply message. This Registration Reply 1373 message MUST also include the Mobile-Home authentication extension, 1374 created using the newly allocated Mobile-Home session key. The home 1375 agent then encodes the Registration Reply message and extensions into 1376 a MIP-Reg-Reply AVP included as part of the HAA message to be sent 1377 back to the AAA server. 1379 5.4 Distributing the Mobile-Foreign Session Key 1381 The Mobile-Foreign session key material is also generated by AAAH 1382 (upon request) and is added to the MIP-MN-to-FA-Key AVP, which is 1383 added to the HAR, and copied by the home agent into a Generalized MN- 1384 FA Key Reply Extension [MIPKEYS] to the Mobile IP Registration Reply 1385 message, using the SPI proposed by the mobile node in the MN-FA Key 1386 Request From AAA Subtype extension. Further, the home agent includes 1387 the SPI in the HAA's MIP-FA-to-MN-SPI AVP. The AAAH includes the 1388 session key in the MIP-FA-to-MN-Key AVP in the HAA, which contains 1389 the session key used by the foreign agent in the computation of the 1390 Mobile-Foreign authentication extension. 1392 If the MIP-FA-to-MN-Key AVP was present in the AMA, the foreign agent 1393 MUST include the Mobile-Foreign authentication extension in the 1394 Registration Reply, using the newly distributed key. 1396 5.5 Distributing the Foreign-Home Session Key 1398 If the home agent is in the home realm, then the AAAH has to generate 1399 the Foreign-Home session key. Otherwise, it is generated by the AAAF. 1401 5.5.1 Home Agent in the home network 1403 In the cases when the AAAH generates the Foreign-Home session key, 1404 the AAAH includes the session key in the MIP-HA-to-FA-Key AVP, and 1405 includes the AVP as part of the HAR message sent to the home agent. 1406 The corresponding session key and algorithm that is to be sent to the 1407 foreign agent is cached in the AAAH until the HAA is received. 1409 Upon receipt of the HAR, the home agent recovers the Foreign-Home 1410 session key, allocates an SPI to be used with the key. The allocated 1411 SPI is included in the HAA's MIP-FA-to-HA SPI AVP. 1413 Upon receipt of the HAA, the AAAH adds the MIP-FA-to-HA Key AVP, 1414 using the SPI in the MIP-FA-to-HA-SPI, and includes the AVP in the 1415 AMA. 1417 5.5.2 Home Agent in foreign network 1419 In the cases when the AAAF generates the Foreign-Home session key 1420 (home agent in foreign domain), the AAAF will, upon receipt of the 1421 HAR message, generate the Foreign-Home session key and include the 1422 session key in the MIP-HA-to-FA-Key AVP as part of the HAR message 1423 forwarded to the home agent. The corresponding session key and 1424 algorithm that is to be sent to the foreign agent is cached in the 1425 AAAF until the HAA is received. 1427 Upon receipt of the HAA, the AAAF creates the MIP-FA-to-HA Key AVP, 1428 using the SPI in the MIP-FA-to-HA-SPI. The AAAF then checks if the 1429 Foreign-Home session key destined for the foreign agent needs to be 1430 encrypted. 1432 If the session key needs to be encrypted, the AAAF will check if a 1433 security association can be established, using the CMS security 1434 application [CMS] with the originating host found in the MIP- 1435 Originating-Foreign-AAA AVP. If the security association 1436 establishment is successful, the AAAF will encrypt the MIP-FA-to-HA 1437 Key AVP with help of the CMS security application [CMS] with the AAAF 1438 as originator and the recipient copied from the MIP-Originating- 1439 Foreign-AAA AVP. The encrypted FA-HA Key is included by the AAAF in 1440 the HAA destined for the AAAH. Otherwise, if the security association 1441 cannot be created, the AAAF MUST return a Result-Code AVP with 1442 DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION. 1444 If the session key does not need to be encrypted, the AAAF will add 1445 MIP-FA-to-HA Key to the HAA, upon reception from the HA and forward 1446 the HAA to the AAAH. 1448 In either case, the AAAF removes the MIP-FA-to-HA-SPI AVP from the 1449 HAA returned to the AAAH. 1451 Upon reception of the HAA, the AAAH MUST copy either the MIP-FA-to-HA 1452 Key AVP if present or the CMS-Encrypted-data AVP if present and not 1453 destined for the AAAH into the AMA. 1455 If a Foreign-Home session key was present in the AMA, the foreign 1456 agent MUST include the Mobile-Foreign authentication extension in the 1457 Registration Reply, using the newly distributed key. 1459 5.6 Key Distribution Example 1461 Figure 9 provides an example of subsequent Mobile IP message 1462 exchange, assuming that AAAH distributed session keys for all three 1463 MN-FA, FA-HA and HA-MN authentication extensions. 1465 Mobile Node Foreign Agent Home Agent 1466 ----------- ------------- ---------- 1468 Reg-Req(MN-HA-Auth, MN-FA-Auth)--------> 1470 Reg-Req(MN-HA-Auth, FA-HA-Auth)--------> 1472 <--------Reg-Rep(MN-HA-Auth, FA-HA-Auth) 1474 <--------Reg-Rep(MN-HA-Auth, MN-FA-Auth) 1476 Figure 9: Mobile IP Message Exchange 1478 6.0 Key Distribution Center (KDC) AVPs 1480 The Mobile-IP protocol defines a set of security associations shared 1481 between the mobile node, foreign agent and home agents. These three 1482 security associations (Mobile-Home, Mobile-Foreign, and Foreign- 1483 Home), can be dynamically created by the AAAH. This requires that the 1484 AAAH create Mobile-IP Session Keys, and that these keys be 1485 distributed to the three mobile entities, via the Diameter Protocol. 1486 AAA servers supporting the Diameter Mobile IP Application MUST 1487 implement the KDC AVPs defined in this document. In other words, AAA 1488 servers MUST be able to create three session keys: the Mobile-Home, 1489 Mobile-Foreign, and Foreign-Home keys. 1491 The names of the KDC AVPs indicate the two entities sharing the 1492 security association defined by the encrypted key material; the 1493 intended receiver of the AVP is the first named entity. So, for 1494 instance, the MIP-MN-to-HA-Key AVP contains the Mobile-Home key 1495 encrypted in a way that allows it to be recovered by the mobile node. 1497 If strong authentication and confidentiality of the session keys is 1498 required, it is recommended that the CMS security application [CMS] 1499 be used. 1501 The following table describes the Diameter AVPs defined in the Mobile 1502 IP application, their AVP Code values, types, possible flag values 1503 and whether the AVP MAY be encrypted. 1505 +---------------------+ 1506 | AVP Flag rules | 1507 |----+-----+----+-----|----+ 1508 AVP Section | | |SHLD| MUST|MAY | 1509 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 1510 -----------------------------------------|----+-----+----+-----|----| 1511 MIP-Algorithm- 345 6.8 Enumerated | M | P | | V | Y | 1512 Type | | | | | | 1513 MIP-FA-to-HA-Key 328 6.2 Grouped | M | P | | V | Y | 1514 MIP-FA-to-HA-SPI 318 6.11 Unsigned32 | M | P | | V | Y | 1515 MIP-FA-to-MN-Key 326 6.1 Grouped | M | P | | V | Y | 1516 MIP-FA-to-MN-SPI 319 6.10 Unsigned32 | M | P | | V | Y | 1517 MIP-HA-to-FA-Key 329 6.3 Grouped | M | P | | V | Y | 1518 MIP-HA-to-MN-Key 332 6.4 Grouped | M | P | | V | Y | 1519 MIP-Key-Lifetime 367 6.13 Unsigned32 | M | P | | V | Y | 1520 MIP-Key-Material 335 6.12 OctetString| M | P | | V | Y | 1521 MIP-MN-to-FA-Key 325 6.5 Grouped | M | P | | V | Y | 1522 MIP-MN-to-HA-Key 331 6.6 Grouped | M | P | | V | Y | 1523 MIP-Replay-Mode 346 6.9 Enumerated | M | P | | V | Y | 1524 MIP-Session-Key 343 6.7 OctetString| M | P | | V | Y | 1526 6.1 MIP-FA-to-MN-Key AVP 1528 The MIP-FA-to-MN-Key AVP (AVP Code 326) is of type Grouped, and 1529 contains the foreign agent's session key, which it shares with the 1530 mobile node. Its Data field has the following ABNF grammar: 1532 MIP-FA-to-MN-Key ::= < AVP Header: 326 > 1533 { MIP-FA-to-MN-SPI } 1534 { MIP-Algorithm-Type } 1535 { MIP-Session-Key } 1536 * [ AVP ] 1538 6.2 MIP-FA-to-HA-Key AVP 1540 The MIP-FA-to-HA-Key AVP (AVP Code 328) is of type Grouped, and 1541 contains the foreign agent's session key, which it shares with the 1542 home agent. Its Data field has the following ABNF grammar: 1544 MIP-FA-to-HA-Key ::= < AVP Header: 328 > 1545 { MIP-FA-to-HA-SPI } 1546 { MIP-Algorithm-Type } 1547 { MIP-Session-Key } 1548 * [ AVP ] 1550 6.3 MIP-HA-to-FA-Key AVP 1552 The MIP-HA-to-FA-Key AVP (AVP Code 329) is of type Grouped, and 1553 contains the Home Agent's session key, which it shares with the 1554 foreign agent. Its Data field has the following ABNF grammar: 1555 MIP-HA-to-FA-Key ::= < AVP Header: 329 > 1556 { MIP-Algorithm-Type } 1557 { MIP-Session-Key } 1558 * [ AVP ] 1560 6.4 MIP-HA-to-MN-Key AVP 1562 The MIP-HA-to-MN-Key AVP (AVP Code 332) is of type Grouped, and 1563 contains the Home Agent's session key, which it shares with the 1564 mobile node. Its Data field has the following ABNF grammar: 1566 MIP-HA-to-MN-Key ::= < AVP Header: 332 > 1567 { MIP-Algorithm-Type } 1568 { MIP-Replay-Mode } 1569 { MIP-Session-Key } 1570 * [ AVP ] 1572 6.5 MIP-MN-to-FA-Key AVP 1574 The MIP-MN-to-FA-Key AVP (AVP Code 325) is of type Grouped, and 1575 contains the mobile node's key material, which it uses to derive the 1576 session key it shares with the foreign agent. The home agent uses 1577 this AVP in the construction of the Mobile IP "Unsolicted MN-FA Key 1578 from AAA Subtype" extension [MIPKEYS]. The SPI in the extension's FA 1579 SPI field is allocated by the home agent, but it SHOULD take into 1580 consideration the SPI requested by the mobile node in the "MN-FA Key 1581 Request From AAA Subtype" extension. 1583 MIP-MN-to-FA-Key ::= < AVP Header: 325 > 1584 { MIP-Algorithm-Type } 1585 { MIP-Key-Material } 1586 { MIP-MN-AAA-SPI } 1587 * [ AVP ] 1589 6.6 MIP-MN-to-HA-Key AVP 1591 The MIP-MN-to-HA-Key AVP (AVP Code 331) is of type Grouped, and 1592 contains the mobile node's key material, which it uses to derive the 1593 session key it shares with the Home Agent. The Home Agent uses this 1594 AVP in the construction of the Mobile IP "Unsolicted MN-HA Key from 1595 AAA Subtype" extension [MIPKEYS]. The SPI in the extension's HA SPI 1596 field is allocated by the Home Agent, but it SHOULD take into 1597 consideration the SPI requested by the mobile node in the "MN-HA Key 1598 Request From AAA Subtype" extension. 1600 MIP-MN-to-HA-Key ::= < AVP Header: 331 > 1601 { MIP-Algorithm-Type } 1602 { MIP-Replay-Mode } 1603 { MIP-Key-Material } 1604 { MIP-MN-AAA-SPI } 1605 * [ AVP ] 1607 6.7 MIP-Session-Key AVP 1609 The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and 1610 contains the Session Key to be used between two Mobile IP entities. 1612 6.8 MIP-Algorithm-Type AVP 1614 The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated, and 1615 contains the Algorithm identifier used to generate the associated 1616 Mobile IP authentication extension. The following values are 1617 currently defined: 1619 1 Prefix+Suffix MD5 [MOBILEIP] 1620 2 HMAC-MD5 [HMAC] 1621 3 HMAC-SHA-1 [HMAC] 1623 6.9 MIP-Replay-Mode AVP 1625 The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and 1626 contains the replay mode the Home Agent should use when 1627 authenticating the mobile node. 1629 The following values are supported (see [MOBILEIP] for more 1630 information): 1632 1 None 1633 2 Timestamps 1634 3 Nonces 1636 6.10 MIP-FA-to-MN-SPI AVP 1638 The MIP-FA-to-MN-SPI AVP (AVP Code 319) is of type Unsigned32, and 1639 contains the Security Parameter Index the foreign agent is to use to 1640 refer to the session key it shares with the mobile node. The SPI 1641 created MUST NOT be a value between zero (0) and 255, which is the 1642 reserved namespace defined in [MOBILEIP]. This AVP MAY be added in 1643 the HAA message by the home agent for the AAAH's use in MIP-FA-to-MN- 1644 SPI AVP of the MIP-FA-to-MN-Key AVP. 1646 6.11 MIP-FA-to-HA-SPI AVP 1648 The MIP-FA-to-HA-SPI AVP (AVP Code 318) is of type Unsigned32, and 1649 contains the Security Parameter Index the foreign agent is to use to 1650 refer to the session key it shares with the home agent. The SPI 1651 created MUST NOT be a value between zero (0) and 255, which is the 1652 reserved namespace defined in [MOBILEIP]. If FA-HA keys are being 1653 generated, this AVP MUST be added in the HAA message by the Home 1654 Agent for the AAAH's (or AAAF's) use in providing the value of the 1655 MIP-FA-to-HA-SPI member of the grouped MIP-FA-to-HA-Key AVP. 1657 6.12 MIP-Key-Material AVP 1659 The MIP-Key-Material AVP (AVP Code 335) is of type OctetString and 1660 contains the key material sent to the mobile node. The mobile node 1661 follows the procedures in [MIPKEYS] to generate the session key used 1662 to authenticate Mobile IP registration messages. 1664 6.13 MIP-Key-Lifetime AVP 1666 The MIP-Key-Lifetime AVP (AVP Code 367) is of type Unsigned32 and 1667 represents the period of time (in seconds) for which the session key 1668 is valid. The session key MUST NOT be used if the lifetime has 1669 expired; if the key lifetime expires while the session to which it 1670 applies is still active, either the session key MUST be changed or 1671 the or the session MUST be terminated. 1673 7.0 Accounting AVPs 1675 This section will define the Accounting AVPs that are specific to 1676 Mobile IP. 1678 7.1 Accounting-Input-Octets AVP 1680 The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64, 1681 and contains the number of octets in IP packets received from the 1682 user. This AVP MUST be included in all Accounting-Request messages 1683 and MAY be present in the corresponding Accounting-Answer messages as 1684 well. 1686 7.2 Accounting-Output-Octets AVP 1688 The Accounting-Output-Octets AVP (AVP Code 364) is of type 1689 Unsigned64, and contains the number of octets in IP packets sent to 1690 the user. This AVP MUST be included in all Accounting-Request 1691 messages and MAY be present in the corresponding Accounting-Answer 1692 messages as well. 1694 7.3 Acct-Session-Time AVP 1696 The Acct-Time AVP (AVP Code 46) is of type Unsigned32, and indicates 1697 the length of the current session in seconds. This AVP MUST be 1698 included in all Accounting-Request messages and MAY be present in the 1699 corresponding Accounting-Answer messages as well. 1701 7.4 Accounting-Input-Packets AVP 1703 The Accounting-Input-Packets (AVP Code 365) is of type Unsigned64, 1704 and contains the number of IP packets received from the user. This 1705 AVP MUST be included in all Accounting-Request messages and MAY be 1706 present in the corresponding Accounting-Answer messages as well. 1708 7.5 Accounting-Output-Packets AVP 1710 The Accounting-Output-Packets (AVP Code 366) is of type Unsigned64, 1711 and contains the number of IP packets sent to the user. This AVP MUST 1712 be included in all Accounting-Request messages and MAY be present in 1713 the corresponding Accounting-Answer messages as well. 1715 7.6 Event-Timestamp AVP 1717 The Event-Timestamp (AVP Code 55) is of type Time, and MAY be 1718 included in an Accounting-Request message to record the time that 1719 this event occurred on the mobility agent, in seconds since January 1720 1, 1970 00:00 UTC. 1722 8.0 AVP Occurrence Tables 1724 The following tables presents the AVPs defined in this document, and 1725 specifies in which Diameter messages they MAY, or MAY NOT be present. 1726 Note that AVPs that can only be present within a Grouped AVP are not 1727 represented in this table. 1729 The table uses the following symbols: 1730 0 The AVP MUST NOT be present in the message. 1731 0+ Zero or more instances of the AVP MAY be present in the 1732 message. 1733 0-1 Zero or one instance of the AVP MAY be present in the 1734 message. 1735 1 One instance of the AVP MUST be present in the message. 1737 8.1 Mobile IP Command AVP Table 1739 The table in this section is limited to the Command Codes defined in 1740 this specification. 1742 +-----------------------+ 1743 | Command-Code | 1744 |-----+-----+-----+-----+ 1745 Attribute Name | AMR | AMA | HAR | HAA | 1746 ------------------------------|-----+-----+-----+-----+ 1747 Authorization-Lifetime | 0-1 | 0-1 | 1 | 0 | 1748 Auth-Application-Id | 1 | 1 | 1 | 1 | 1749 Auth-Session-State | 0-1 | 0-1 | 1 | 0 | 1750 Acct-Multi-Session-Id | 0-1 | 0-1 | 0 | 0-1 | 1751 Destination-Host | 0-1 | 0 | 0-1 | 0 | 1752 Destination-Realm | 1 | 0 | 1 | 0 | 1753 Error-Message | 0 | 0-1 | 0 | 0-1 | 1754 Error-Reporting-Host | 0 | 0-1 | 0 | 0-1 | 1755 MIP-Candidate-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 | 1756 MIP-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 | 1757 MIP-Originating-Foreign-AAA | 0-1 | 0 | 0-1 | 0 | 1758 MIP-FA-Challenge | 0-1 | 0 | 0 | 0 | 1759 MIP-FA-to-HA-Key | 0 | 0-1 | 0-1 | 0 | 1760 MIP-FA-to-HA-SPI | 0 | 0 | 0 | 0-1 | 1761 MIP-FA-to-MN-Key | 0 | 0-1 | 0 | 0 | 1762 MIP-FA-to-MN-SPI | 0 | 0 | 0 | 0-1 | 1763 MIP-Feature-Vector | 0-1 | 0-1 | 1 | 0 | 1764 MIP-Filter-Rule | 0 | 0+ | 0+ | 0 | 1765 MIP-HA-to-FA-Key | 0 | 0-1 | 0-1 | 0 | 1766 MIP-HA-to-MN-Key | 0 | 0-1 | 0-1 | 0 | 1767 MIP-Home-Agent-Address | 0-1 | 0-1 | 0-1 | 0-1 | 1768 MIP-Key-Lifetime | 0 | 0-1 | 0-1 | 0 | 1769 MIP-MN-AAA-Auth | 1 | 0 | 0 | 0 | 1770 MIP-MN-to-FA-Key | 0 | 0-1 | 0-1 | 0 | 1771 MIP-MN-to-HA-Key | 0 | 0-1 | 0-1 | 0 | 1772 MIP-Mobile-Node-Address | 0-1 | 0-1 | 0-1 | 0-1 | 1773 MIP-Reg-Reply | 0 | 0-1 | 0 | 0-1 | 1774 MIP-Reg-Request | 1 | 0 | 1 | 0 | 1775 Origin-Host | 1 | 1 | 1 | 1 | 1776 Origin-Realm | 1 | 1 | 1 | 1 | 1777 Origin-State-Id | 0-1 | 0-1 | 0-1 | 0-1 | 1778 Proxy-Info | 0+ | 0+ | 0+ | 0+ | 1779 Redirect-Host | 0 | 0+ | 0 | 0+ | 1780 Redirect-Host-Usage | 0 | 0-1 | 0 | 0-1 | 1781 Redirect-Max-Cache-Time | 0 | 0-1 | 0 | 0-1 | 1782 Result-Code | 0 | 1 | 0 | 1 | 1783 Re-Auth-Request-Type | 0 | 0-1 | 0 | 0 | 1784 Route-Record | 0+ | 0 | 0+ | 0 | 1785 Session-Id | 1 | 1 | 1 | 1 | 1786 User-Name | 1 | 0-1 | 1 | 0-1 | 1787 ------------------------------|-----+-----+-----+-----| 1789 8.2 Accounting AVP Table 1791 The table in this section is used to represent which AVPs defined in 1792 this document are to be present in the Accounting messages, defined 1793 in [DIAMBASE]. 1795 +-------------+ 1796 | Command-Code| 1797 |------+------+ 1798 Attribute Name | ACR | ACA | 1799 -------------------------------------|------+------+ 1800 Accounting-Input-Octets | 1 | 0-1 | 1801 Accounting-Input-Packets | 1 | 0-1 | 1802 Accounting-Output-Octets | 1 | 0-1 | 1803 Accounting-Output-Packets | 1 | 0-1 | 1804 Acct-Multi-Session-Id | 1 | 0-1 | 1805 Acct-Session-Time | 1 | 0-1 | 1806 MIP-Feature-Vector | 1 | 0-1 | 1807 MIP-Home-Agent-Address | 1 | 0-1 | 1808 MIP-Mobile-Node-Address | 1 | 0-1 | 1809 Event-Timestamp | 0-1 | 0 | 1810 -------------------------------------|------+------+ 1812 9.0 IANA Considerations 1814 This section contains the namespaces that have either been created in 1815 this specification, or the values assigned to existing namespaces 1816 managed by IANA. 1818 9.1 Command Codes 1820 This specification assigns the values 260 and 262 from the Command 1821 Code namespace defined in [DIAMBASE]. See section 2.0 for the 1822 assignment of the namespace in this specification. 1824 9.2 AVP Codes 1826 This specification assigns the values 318-348 and 363-367 from the 1827 AVP Code namespace defined in [DIAMBASE]. See sections 4.0 and 6.0 1828 for the assignment of the namespace in this specification. 1830 9.3 Result-Code AVP Values 1832 This specification assigns the values 4005-4007, and 5024-5025 from 1833 the Result-Code AVP (AVP Code 268) value namespace defined in 1834 [DIAMBASE]. See section 3.0 for the assignment of the namespace in 1835 this specification. 1837 9.4 MIP-Feature-Vector AVP Values 1839 There are 32 bits in the MIP-Feature-Vector AVP (AVP Code 337) that 1840 are available for assignment. This document assigns bits 1-9, as 1841 listed in section 4.5. The remaining bits should only be assigned via 1842 Standards Action [IANA]. 1844 9.5 MIP-Algorithm-Type AVP Values 1846 As defined in Section 6.8, the MIP-Algorithm-Type AVP (AVP Code 345) 1847 defines the values 1-3. All remaining values are available for 1848 assignment via Designated Expert [IANA]. 1850 9.6 MIP-Replay-Mode AVP Values 1852 As defined in Section 6.9, the MIP-Replay-Mode AVP (AVP Code 346) 1853 defines the values 1-3. All remaining values, except zero, are 1854 available for assignment via Designated Expert [IANA]. 1856 9.7 Application Identifier 1858 This specification assigns the value four (4) to the Application 1859 Identifier namespace defined in [DIAMBASE]. See section 1.7 for more 1860 information. 1862 10.0 Security Considerations 1864 This specification describes the Diameter Application necessary to 1865 authenticate and authorize a Mobile IP mobile node. The 1866 authentication algorithm used is dependent upon the transforms 1867 available by the Mobile IP protocol, and [MIPCHAL]. This 1868 specification also defines a method by which the home Diameter server 1869 can create and distribute session keys to be used to authenticate 1870 Mobile IP registration messages. The keys SHOULD be be protected 1871 using the methods defined in [CMS]. 1873 11.0 References 1875 11.1 Normative 1877 [DIAMBASE] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens, 1878 "Diameter Base Protocol", draft-ietf-aaa-diameter-11.txt, 1879 IETF work in progress, June 2002. 1881 [IANA] Narten, Alvestrand,"Guidelines for Writing an IANA Con� 1882 siderations Section in RFCs", BCP 26, RFC 2434, October 1883 1998 1885 [MOBILEIP] C. Perkins, Editor. IP Mobility Support. RFC 3220, Jan� 1886 uary 2002. 1888 [MIPCHAL] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response 1889 Extensions". RFC 3012. November 2000. 1891 [NAI] B. Aboba, M. Beadles "The Network Access Identifier." RFC 1892 2486. January 1999. 1894 [HMAC] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed- 1895 Hashing for Message Authentication. RFC 2104, February 1896 1997. 1898 [MIPKEYS] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile 1899 IP", draft-ietf-mobileip-aaa-key-09.txt, IETF work in 1900 progress, July 2001. 1902 [AAANAI] F. Johansson, T.Johansson, "AAA NAI for Mobile IPv4 1903 Extension", draft-mobileip-aaa-nai-02.txt, IETF work in 1904 progress, May 2002. 1906 11.2 Informative 1908 [MIPREQ] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentica� 1909 tion, Authorization, and Accounting Requirements". RFC 1910 2977. October 2000. 1912 [CDMA2000] T. Hiller and al, "CDMA2000 Wireless Data Requirements 1913 for AAA", RFC 3141, June 2001. 1915 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 1916 Requirement Levels", BCP 14, RFC 2119, March 1997. 1918 [EVALROAM] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Pro� 1919 tocols", RFC 2477, January 1999. 1921 [MIPNAI] P. Calhoun, C. Perkins, "Mobile IP Network Address Iden� 1922 tifier Extension", RFC 2794, March 2000. 1924 [CMS] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security 1925 Application", draft-ietf-aaa-diameter-cms-sec-05.txt, 1926 IETF work in progress, April 2002. 1928 [RANDOM] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Random� 1929 ness Recommendations for Security. Request for Comments 1930 (Informational) 1750, Internet Engineering Task Force, 1931 December 1994. 1933 12.0 Acknowledgements 1935 The authors would like to thank Nenad Trifunovic, Haseeb Akhtar and 1936 Pankaj Patel for their participation in the pre-IETF Document Reading 1937 Party, to Erik Guttman for his very useful proposed text, and to 1938 Fredrik Johansson, Martin Julien and Bob Kopacz for their very useful 1939 contributed text. 1941 The authors would also like to thank the participants of 3GPP2's TSG- 1942 P working group for their valuable feedback and also the following 1943 people for their contribution in the development of the protocol: 1945 Kevin Purser, Thomas Panagiotis, Mark Eklund, Paul Funk, Michael 1946 Chen, Henry Haverinen, Johan Johansson 1948 Finally, Pat Calhoun would like to thank Sun Microsystems since most 1949 of the effort put into this document was done while he was in their 1950 employ. 1952 13.0 Authors' Addresses 1954 Questions about this memo can be directed to: 1956 Pat R. Calhoun 1957 Black Storm Networks 1958 250 Cambridge Avenue, Suite 200 1959 Palo Alto, California, 94306 1960 USA 1962 Phone: +1 650-617-2932 1963 Fax: +1 650-786-6445 1964 E-mail: pcalhoun@bstormnetworks.com 1965 Tony Johansson 1966 Ericsson Inc 1967 2100 Shattuck Avenue 1968 Berkeley, California 94704 1969 USA 1971 Phone: +1 510-541-8783 1972 Fax: +1 510-666-3900 1973 E-Mail: tony.johansson@ericsson.com 1975 Charles E. Perkins 1976 Nokia Research Center 1977 313 Fairchild Drive 1978 Mountain View, California 94043 1979 USA 1981 Phone: +1 650-625-2986 1982 Fax: +1 650-625-2502 1983 E-Mail: charliep@iprg.nokia.com 1985 Copyright (C) The Internet Society (2001). All Rights Reserved. 1987 This document and translations of it may be copied and furnished to 1988 others, and derivative works that comment on or otherwise explain it 1989 or assist in its implementation may be prepared, copied, published 1990 and distributed, in whole or in part, without restriction of any 1991 kind, provided that the above copyright notice and this paragraph are 1992 included on all such copies and derivative works. However, this docu� 1993 ment itself may not be modified in any way, such as by removing the 1994 copyright notice or references to the Internet Society or other 1995 Internet organizations, except as needed for the purpose of develop� 1996 ing Internet standards in which case the procedures for copyrights 1997 defined in the Internet Standards process must be followed, or as 1998 required to translate it into languages other than English. The lim� 1999 ited permissions granted above are perpetual and will not be revoked 2000 by the Internet Society or its successors or assigns. This document 2001 and the information contained herein is provided on an "AS IS" basis 2002 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS� 2003 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 2004 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2005 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 2006 FITNESS FOR A PARTICULAR PURPOSE. 2008 15.0 Expiration Date 2010 This memo is filed as and 2011 expires in December 2002.