idnits 2.17.1 draft-ietf-aaa-diameter-mobileip-10.txt: -(1910): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1913): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1984): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1987): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1990): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1994): 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 47 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 48 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 (April 2002) is 8037 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 April 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-Foreign-Agent-Host AVP 80 4.9 MIP-Filter-Rule AVP 81 4.10 MIP-Candidate-Home-Agent-Host 82 4.11 MIP-Originating-Foreign-AAA AVP 83 4.12 MIP-Home-Agent-Host AVP 84 5.0 Key Distribution Center 85 5.1 Authorization Lifetime vs. MIP Key Lifetime 86 5.2 Key Material vs. Session Key 87 5.3 Distributing the Mobile-Home Session Key 88 5.4 Distributing the Mobile-Foreign Session Key 89 5.5 Distributing the Foreign-Home Session Key 90 5.6 Key Distribution Example 91 6.0 Key Distribution Center (KDC) AVPs 92 6.1 MIP-FA-to-MN-Key AVP 93 6.2 MIP-FA-to-HA-Key AVP 94 6.3 MIP-HA-to-FA-Key AVP 95 6.4 MIP-HA-to-MN-Key AVP 96 6.5 MIP-MN-to-FA-Key AVP 97 6.6 MIP-MN-to-HA-Key AVP 98 6.7 MIP-Session-Key AVP 99 6.8 MIP-Algorithm-Type AVP 100 6.9 MIP-Replay-Mode AVP 101 6.10 MIP-FA-to-MN-SPI 102 6.11 MIP-FA-to-HA-SPI 103 6.12 MIP-Key-Material AVP 104 6.13 MIP-Key-Lifetime AVP 105 7.0 Accounting AVPs 106 7.1 Accounting-Input-Octets AVP 107 7.2 Accounting-Output-Octets AVP 108 7.3 Acct-Session-Time AVP 109 7.4 Accounting-Input-Packets AVP 110 7.5 Accounting-Output-Packets AVP 111 7.6 Event-Timestamp AVP 112 8.0 AVP Table 113 8.1 Mobile IP Command AVP Table 114 8.2 Accounting AVP Table 115 9.0 IANA Considerations 116 9.1 Command Codes 117 9.2 AVP Codes 118 9.3 Result-Code AVP Values 119 9.4 MIP-Feature-Vector AVP Values 120 9.5 MIP-Algorithm-Type AVP Values 121 9.6 MIP-Replay-Mode AVP Values 122 9.7 Application Identifier 123 10.0 Security Considerations 124 11.0 References 125 11.1 Normative 126 11.2 Informative 127 12.0 Acknowledgements 128 13.0 Authors' Addresses 129 14.0 Full Copyright Statement 130 15.0 Expiration Date 132 1.0 Introduction 134 Mobile IP, as defined in [MOBILEIP], defines a method that allows a 135 Mobile Node to change its point of attachment to the Internet with 136 minimal service disruption. Mobile IP does not provide any specific 137 support for mobility across disparate administrative domains, and 138 therefore does not specify how usage can be accounted for, which has 139 limited the applicability of Mobile IP in a IPv4 commercial 140 deployment. The Mobile IP specification as defined in [MOBILEIP] 141 recommends mobile nodes to have a static home address and a home 142 agent. However this may not be always possible in certain deployment 143 scenarios. Recent developments in areas that impact IP mobility in 144 the IETF allow Mobile IP [MOBILEIP] to work just as well when mobile 145 nodes do not have a static home agent and home address. In addition, 146 another specification [MIPNAI] allows a mobile node to use its NAI 147 instead of its home address, which better accommodates current 148 administrative practice. 150 This document specifies an Application of 4 to the Diameter base 151 protocol [DIAMBASE] that allows a Diameter server to authenticate, 152 authorize and collect accounting information for Mobile IPv4 services 153 rendered to a mobile node. This application MUST NOT be used in 154 conjunction with the Mobile IPv6 protocol. 156 Combined with the Inter-Realm capability of the base protocol, this 157 application allows mobile nodes to receive service from foreign 158 service providers. The Diameter Accounting messages will be used by 159 the foreign and home agents to transfer usage information to the 160 Diameter servers. 162 The Mobile IP protocol [MOBILEIP] specifies a security model that 163 requires that mobile nodes and home agents share a pre-existing 164 security association, which leads to scaling and configuration 165 issues. This specification defines Diameter functions that allow the 166 AAA server to act as a Key Distribution Center (KDC), whereby dynamic 167 session keys are created and distributed to the mobility entities for 168 the purposes of securing Mobile IP Registration messages. 170 Strong authentication and confidentiality of session keys is 171 required, and it is recommended to be provided using the CMS security 172 application [CMS], but may be provided via other security mechanisms, 173 e.g. using mutually authenticated TLS or IPsec when deployed in an 174 environment without Diameter agents, then hop-by-hop security is 175 sufficient for protecting session keys. (It should be noted that the 176 CMS security application is referenced as informative in this 177 application and the usage is only a recommendation.) However, if a 178 home AAA server is explicitly configured to need the CMS security 179 application for this domain/transaction then it will not proceed 180 without it, that is, the requested service MUST fail if CMS isn't 181 available. 183 As with the Diameter base protocol, AAA servers implementing the 184 Mobile IP application can process users' identities supplied in a 185 Network Access Identifier (NAI) format [NAI], which is used for 186 Diameter message routing purposes. Mobile nodes include their NAI in 187 Registration messages, as defined in [MIPNAI]. The use of the NAI is 188 consistent with the roaming model defined by the ROAMOPS Working 189 Group [EVALROAM]. 191 A home AAA server (AAAH) and foreign AAA server (AAAF), which support 192 the Mobile-IP authentication application MAY maintain session-state 193 or MAY be session-stateless. AAA redirect agents and AAA relay agents 194 MUST not maintain session-state. The AAAH, AAAF, proxies and relays 195 agents MUST maintain transaction state. 197 Given the nature of Mobile IP, a re-authentication can only be 198 initiated by a mobile node, which does not participate in the 199 Diameter message exchanges. Therefore Diameter server initiated re- 200 auth does not apply to this application. 202 Furthermore, the nature of mobile IP also means that the mobile node 203 will do handoffs between different foreign agents and to guarantee 204 that a registered user always ends up in the same initial AAAH the 205 Mobile Node MUST always include the AAAH NAI [AAANAI]. Finally, to 206 assist the AAAH in routing the messages to a mobile node's home agent 207 the mobile node MUST always include the HA NAI [AAANAI]. 209 The Diameter Mobile-IP Application meets the requirements specified 210 in [MIPREQ, CDMA2000]. Later subsections in this introductory section 211 provide some examples and message flows of the Mobile IP and Diameter 212 messages that occur when a Mobile Node requests service in a foreign 213 network. In this document, the role of the "attendant" [MIPREQ] is 214 performed by either the home agents (for co-located mobile nodes) or 215 foreign agents for the Mobile-IP Application, and these terms will be 216 used interchangeably. 218 1.1 Requirements language 220 In this document, the key words "MAY", "MUST", "MUST NOT", 221 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 222 interpreted as described in [KEYWORDS]. 224 1.2 Inter-Realm Mobile IP 226 When a Mobile Node node requests service by issuing a Registration 227 Request to the foreign agent, the foreign agent creates the AA- 228 Mobile-Node-Request (AMR) message, which includes the AVPs defined in 229 section 2.1. The Home Address, Home Agent, Mobile Node NAI and other 230 important fields are extracted from the registration messages for 231 possible inclusion as Diameter AVPs. The AMR message is then 232 forwarded to the local Diameter server, known as the AAA-Foreign, or 233 AAAF. 235 Visited Realm Home Realm 236 +--------+ +--------+ 237 |abc.com | AMR/AMA |xyz.com | 238 | AAAF |<------------------->| AAAH | 239 +->| server | server-server | server | 240 | +--------+ communication +--------+ 241 | ^ ^ 242 | AMR/AMA | client-server | HAR/HAA 243 | | communication | 244 v v v 245 +---------+ +---------+ +---------+ 246 | Foreign | | Foreign | | Home | 247 | Agent | | Agent | | Agent | 248 +---------+ +---------+ +---------+ 249 ^ 250 | Mobile IP 251 | 252 v 253 +--------+ 254 | Mobile | 255 | Node | mn@xyz.com 256 +--------+ 257 Figure 1: Inter-Realm Mobility 259 Upon receiving the AMR, the AAAF follows the procedures outlined in 260 [DIAMBASE] to determine whether the AMR should be processed locally, 261 or if it should be forwarded to another Diameter server, known as the 262 AAA-Home, or AAAH. Figure 1 shows an example in which a mobile node 263 (mn@xyz.com) requests service from a foreign provider (abc.com). The 264 request received by the AAAF is forwarded to xyz.com's AAAH server. 266 Figure 2 shows the message flows involved when the foreign agent 267 invokes the AAA infrastructure to request that a mobile node be 268 authenticated and authorized. Note that it is not required that the 269 foreign agent invoke AAA services every time a Registration Request 270 is received from the mobile, but rather only when the prior 271 authorization from the AAAH expires. The expiration time of the 272 authorization is communicated through the Authorization-Lifetime AVP 273 in the AA-Mobile-Node-Answer (AMA, see section 2.2) from the AAAH. 275 Mobile Node Foreign Agent AAAF AAAH Home Agent 276 ----------- ------------- ------------ ---------- ---------- 277 Advertisement & 278 <--------- Challenge 280 Reg-Req&MN-AAA ----> 282 AMR------------> 283 Session-Id = foo 285 AMR------------> 286 Session-Id = foo 288 HAR-----------> 289 Session-Id = bar 291 <----------HAA 292 Session-Id = bar 294 <-----------AMA 295 Session-Id = foo 297 <------------AMA 298 Session-Id = foo 300 <-------Reg-Reply 302 Figure 2: Mobile IP/Diameter Message Exchange 304 The foreign agent (as shown in Figure 2) MAY provide a challenge, 305 which gives it direct control over the replay protection in the 306 Mobile IP registration process, as described in [MIPCHAL]. The 307 mobile node includes the Challenge and MN-AAA authentication 308 extension to enable authorization by AAAH. If the authentication data 309 supplied in the MN-AAA extension is invalid, AAAH returns the 310 response (AMA) with the Result-Code AVP set to 311 DIAMETER_AUTHENTICATION_REJECTED. 313 A mobile node, which has been previously authenticated and 314 authorized, MUST always include the assigned home agent in the HA 315 Identity subtype of the AAA NAI extension, and the authorizing Home 316 AAA server in the AAAH Identity subtype of the AAA NAI extension, in 317 the registration request message [AAANAI] which is sent to the FA 318 every time the Mobile Node needs to re-authenticate. So, in the event 319 that the AMR generated by the FA is for a session that was previously 320 authorized, it MUST include the Destination-Host AVP, with the 321 identity of the AAAH found in the AAAH-NAI, and the MIP-Home-Agent- 322 Host AVP with the identity and realm of the assigned HA found in the 323 HA-NAI. 325 If the mobile node was successfully authenticated, the AAAH checks if 326 the home agent was located in the foreign realm, by checking Home- 327 Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. Other 328 AVP's like the MIP-Home-Agent-Host AVP and the MIP-Originating- 329 Foreign-AAA AVP may also be used to verify the location of the home 330 agent. If the home agent is located in the foreign realm, then the 331 AAAH sends an HAR message to the home agent, which contains a MIP- 332 Reg-Request AVP. 334 If the home agent was not located in the foreign realm, the AAAH 335 checks for the MIP-Home-Agent-Address AVP and if present the MIP- 336 Home-Agent-Host AVP. If one was specified, the AAAH checks that the 337 address is that of a known home agent and that the Mobile Node is 338 allowed to request this particular home agent, and that the home 339 agent's identity is included in the MIP-Home-Agent-Host AVP. If no 340 home agent was specified, and if the MIP-Feature-Vector has the Home- 341 Agent-Requested flag set, and if allowed by policy in the home realm, 342 the AAAH SHOULD allocate a home agent on behalf of the Mobile Node. 343 This can be done in a variety of ways, including using a load 344 balancing algorithm in order to keep the load on all home agents 345 equal. The actual algorithm used and the method of discovering the 346 home agents is outside the scope of this specification. 348 The AAAH then sends an Home-Agent-MIP-Request (HAR), which contains 349 the Mobile IP Registration Request message data encapsulated in the 350 MIP-Reg-Request AVP, to the assigned or requested Home Agent. The 351 AAAH MAY allocate a home address for the mobile node, while the Home 352 Agent MUST support home address allocation. In the event the AAAH 353 handles address allocation, it includes it in a MIP-Mobile-Node- 354 Address AVP within the HAR. The absence of this AVP informs the Home 355 Agent to perform the allocation. 357 During the creation of the HAR, the AAAH MUST use a different session 358 identifier than the one used in the AMR/AMA (see Figure 2). If the 359 AAAH is session-stateful, it MUST send the same session identifier 360 for all HARs initiated on behalf of a given mobile node's session. 361 Otherwise, if the AAAH is session-stateless, it will manufacture a 362 unique session-id for every HAR. 364 A mobile node's session is identified via its identity in the User- 365 Name AVP, the MIP-Mobile-Node-Address and the MIP-Home-Agent-Address 366 AVPs. This is necessary in order to allow the session state machine, 367 defined in the base protocol [DIAMBASE], to be used unmodified with 368 this application. Therefore, an STR from a foreign agent would free 369 the session from the foreign agent, but not the one towards the home 370 agent (see figure 3). 372 STR, Session-Id = foo STR, Session-Id = bar 373 ---------------------> <-------------------- 374 +----+ +------+ +------+ +----+ 375 | FA | | AAAF | | AAAH | | HA | 376 +----+ +------+ +------+ +----+ 377 <--------------------- ---------------------> 378 STA, Session-Id = foo STA, Session-Id = bar 379 Figure 3: Session Termination and Session Identifiers 381 Upon receipt of the HAR, the home agent first processes the Diameter 382 message. The home agent processes the MIP-Reg-Request AVP and creates 383 the Registration Reply, encapsulating it within the MIP-Reg-Reply 384 AVP. In the creation of the Registration Reply the Home Agent must 385 include the HA NAI and the AAAH NAI, which will be created from the 386 Origin-Host AVP and Origin-Realm AVP of the HAR. If a home address is 387 needed, the home agent MUST also assign one and include the address 388 in both the Registration Reply and within the MIP-Mobile-Node-Address 389 AVP. 391 The HA MUST include an Accounting-Multi-Session-Id AVP in the HAA 392 returned to the AAAH. 394 Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer 395 (AMA) message, includes the Accounting-Multi-Session-Id that was 396 present in the HAA, and the MIP-Home-Agent-Address, MIP-Mobile-Node- 397 Address AVPs in the AMA message, enabling appropriate firewall 398 controls for the penetration of tunneled traffic between the Home 399 Agent and the Mobile Node. 401 1.3 Support for Mobile IP Handoffs 403 Given the nature of Mobile IP, a mobile node MAY receive service from 404 many foreign agents during a period of time. However, the home realm 405 should not view these handoffs as different sessions, since this 406 could affect billing systems. Furthermore, many foreign agents do not 407 communicate, which makes it quite difficult for AAA information to be 408 exchanged between these entities. Therefore, it MUST be assumed that 409 a foreign agent is not aware that a registration request from a 410 mobile node has been previously authorized. 412 A handoff registration request from a mobile node will cause an AMR 413 to be sent to its AAAF. The AMR will include a new session 414 identifier, and MAY be sent to an AAAF in the visited network other 415 than the AAAF, which received the previous AMR. However, with the 416 usage of the AAA NAI, this AMR is guaranteed to be received by the 417 AAAH to which the user is currently registered. 419 Since the AAAH may be session-stateless, it is necessary for the 420 resulting HAR received by the HA to be identified as a continuation 421 of an existing session. If the HA receives an HAR for a mobile node, 422 with a new session identifier, and the HA can guarantee that this 423 request is to extend service for an existing service, then the HA 424 MUST be able to modify its internal session state information to 425 reflect the new session identifier. 427 It is necessary for accounting records to have some commonality 428 across handoffs in order for correlation to occur. Therefore, the 429 home agent MUST send the same Accounting-Multi-Session-Id AVP value 430 in all HAAs for the mobile's session. That is, the HA generates a 431 unique Accounting-Multi-Session-Id when receiving an HAR for a new 432 session, and returns this same value in every HAA for the session. 433 This Accounting-Multi-Session-Id AVP will be returned to the foreign 434 agent by the AAAH in the AMA. Both the foreign and home agents MUST 435 include the Accounting-Multi-Session-Id in the accounting messages. 437 ACR, Session-Id = foo ACR, Session-Id = bar 438 Accounting-Multi-Session-Id = a Accounting-Multi-Session-Id = a 439 ---------------------> <-------------------- 440 +----+ +------+ +------+ +----+ 441 | FA | | AAAF | | AAAH | | HA | 442 +----+ +------+ +------+ +----+ 443 <--------------------- ---------------------> 444 ACA, Session-Id = foo ACA, Session-Id = bar 446 Figure 4: Accounting messages w/ Mobile IP Application 448 1.4 Allocation of Home Agent in Foreign Network 450 The Diameter Mobile IP application allows a home agent to be 451 allocated in a foreign network, as required in [MIPREQ, CDMA2000]. 452 When a foreign agent detects that the mobile node has a home agent 453 address equal to 0.0.0.0 or 255.255.255.255 in the Registration 454 Request message, it MUST add a MIP-Feature-Vector AVP with the Home- 455 Agent- Requested flag set to one. If the home agent address is equal 456 to 255.255.255.255, then the foreign agent also MUST set the Home- 457 Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home 458 agent address is set to 0.0.0.0, the foreign agent MUST set the Home- 459 Address-Allocatable-Only-in-Home-Realm flag equal to zero. 461 When the AAAF receives an AMR message with the Home-Agent-Requested 462 flag set to one, and the Home-Address-Allocatable-Only-in-Home-Realm 463 flag equal to zero, the AAAF MAY set the Foreign-Home-Agent-Available 464 flag in the MIP-Feature-Vector AVP to inform the AAAH that it is 465 willing and able to assign a Home Agent for the Mobile Node. When 466 doing so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host AVP 467 and the MIP-Originating-Foreign-AAA-AVP. The MIP-Candidate-Home- 468 Agent-Host AVP contains the identity of the home agent that would be 469 assigned to the mobile node and the MIP-Originating-Foreign-AAA AVP 470 contains the identity of the AAAF. 472 In the event that the mobile node has been previously authorized by 473 the AAAH and now needs to be re-authenticated, and requests to keep 474 the assigned home agent in the foreign network, the mobile node MUST 475 include the HA NAI and the AAAH NAI in the registration request to 476 the FA. Upon receipt, the FA will create the AMR including the MIP- 477 Home-Agent-Address AVP, the Destination-Host AVP based on the AAAH 478 NAI and instead of the MIP-Candidate-Home-Agent-Host AVP include the 479 MIP-Home-Agent-Host AVP based on the home agent NAI. If the AAAF 480 authorizes the use of the requested home agent, the AAAF MUST set the 481 Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. 483 When the AAAH receives an AMR message, it first checks the 484 authentication data supplied by the mobile node, according to the 485 MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether 486 to authorize the mobile node. If the AMR indicates that the AAAF has 487 offered to allocate a Home Agent for the mobile node, i.e. the 488 Foreign-Home-Agent-Available is set in the MIP-Feature-Vector AVP, or 489 the AMR indicates that the AAAF has offered a previously allocated 490 Home Agent for the mobile node, i.e. the Home-Agent-In-Foreign- 491 Network is set in the MIP-Feature-Vector AVP, then the AAAH must 492 decide whether its local policy would allow the user to have a Home 493 Agent in the foreign network or to keep the Home Agent in the foreign 494 network. If so, and after checking authorization from the data in the 495 AMR message, the AAAH sends the HAR message to Home Agent by 496 including the Destination-Host AVP set to the value found in the 497 AMR's MIP-Candidate-Home-Agent-Host AVP or MIP-Home-Agent-Host AVP if 498 the HA has been previously allocated and authorized by the AAAH. If 499 the HA has not been previously allocated by the foreign domain, the 500 HAR sent by the AAAH does not contain the MIP-Home-Agent-Address. 502 If the AAAH's local policy determines that the MN-HA Key and/or the 503 MN-FA Key must be encrypted, the AAAH sends the HAR to the 504 originating AAAF. In this HAR the Destination-Host AVP is set to the 505 value found in the AMR's MIP-Originating-Foreign-AAA AVP, and the 506 MIP-Home-Agent-Host AVP or the MIP-Candidate-Home-Agent-Host AVP 507 found in the AMR are copied into the HAR. If no security association 508 exists between the AAAH and the originating AAAF, the AAAH will make 509 use of the CMS application [CMS] to establish this association. 510 However, if no security association cannot be established the AAAH 511 MUST return an AMA with the Result-Code AVP set to 512 DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION. 514 If the AAAH's local policy determines that no keys need to be 515 encrypted, the HAR is sent by the AAAH back to the foreign realm with 516 the Destination-Host AVP set to the home agent's identity. This HAR 517 may not necessarily be received by the same AAAF, which sent the AMR. 518 Therefore the AAAH MUST always copy the MIP-Originating-Foreign-AAA 519 AVP from the AMR message to the HAR message. In cases when another 520 AAAF receives the HAR, this new AAAF will use the MIP-Originating- 521 Foreign-AAA AVP for policy decisions, such as determining if the FA- 522 HA Key should be encrypted or not. 524 Visited Home 525 Realm Realm 526 +--------+ ------- AMR -------> +--------+ 527 | AAAF | <------ HAR -------- | AAAH | 528 | | | | 529 +--->| server | ------- HAA -------> | server | 530 | +--------+ <------ AMA -------- +--------+ 531 | ^ | 532 | | | 533 HAR/HAA | AMR | | AMA 534 v | v 535 +---------+ +---------+ 536 | Home | | Foreign | 537 | Agent | | Agent | 538 +---------+ +---------+ 539 ^ 540 +--------+ | 541 | Mobile |<----------+ 542 | Node | Mobile IP 543 +--------+ 544 Figure 5: Home Agent allocated in Visited Realm 546 Upon receipt of a HAA from the Home Agent in the visited realm, the 547 AAAF forwards the HAA to the AAAH in the home realm. The AMA is then 548 constructed, and issued to the AAAF, and finally to the FA. If the 549 Result-Code indicates success, the HAA and AMA MUST include the MIP- 550 Home-Agent-Address and the MIP-Mobile-Node-Address AVPs. 552 Mobile Node Foreign Agent Home Agent AAAF AAAH 553 ----------- ------------- ------------- ---------- ---------- 555 <----Challenge---- 556 Reg-Req (Response)-> 557 ------------AMR-------------> 558 -----AMR----> 559 <----HAR----- 560 <-----HAR------ 561 ------HAA------> 562 -----HAA----> 563 <----AMA----- 564 <-------------AMA------------ 565 <---Reg-Reply---- 566 Figure 6: Mobile IP/Diameter Message Exchange 568 If the Mobile Node moves to another Foreign Network, it MAY either 569 request to keep the same Home Agent within the old foreign network, 570 or request to get a new one in the new foreign network. If the AAAH 571 is willing to provide the requested service, the mobile node will 572 have to be serviced by two AAAFs. 574 Figure 7 shows the message flows for a mobile node requesting to keep 575 the home agent assigned in foreign network 1 when it moves to foreign 576 network 2. Upon reception of the AMR in Foreign network 2, the AAAF 577 follows the procedures described earlier and forwards AMR to the 578 mobile node's home network, i.e. its AAAH. If the mobile node was 579 successfully authenticated, the AAAH checks the identity of the 580 foreign and home agent to determine whether the user is in a third 581 realm. If this is the case, the AAAH must check whether the mobile is 582 still permitted to use the previously assigned home agent. 584 +---------------+ +---------------+ +-------------+ 585 |Foreign net 2 | |Foreign net 1 | |Home network | 586 | | | | | | 587 Mobile Node | FA AAAF | | HA AAAF | | AAAH | 588 ----------- | ---- ---- | | ---- ------ | | ------ | 589 +---------------+ +---------------+ +-------------+ 591 <----Challenge---- 592 Reg-Req (Response)-> 593 ---AMR---> 594 ----------------AMR---------------> 595 <-----HAR----- 596 <---HAR---- 597 ----HAA---> 598 ------HAA----> 599 <---------------AMA---------------- 600 <--AMA---- 601 <----Reg-Reply----- 602 Figure 7: Request to access Home Agent from new Foreign Network 604 If the mobile node is allowed to keep the home agent the AAAH then 605 sends a HAR, which contains the Mobile IP Registration Request 606 message data encapsulated in the MIP-Reg-Request AVP and the MIP- 607 Home-Agent-Address AVP with home agent address, as well as any 608 optional KDC session keys, to the AAAF in foreign network 1. 609 Furthermore, the AAAH MUST always copy MIP-Originating-Foreign-AAA 610 AVP from AMR and include it in the HAR when a third foreign domain is 611 involved, since the AAAF will use the MIP-Originating-Foreign-AAA AVP 612 for policy decisions, such as determining if the FA-HA Key should be 613 encrypted or not. Upon reception the AAAF in foreign network 1 will 614 forward the HAR to the Home Agent if its local policy allows such 615 service. If the AAAF does not permit such service, it MUST return a 616 DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. 618 If the AAAH local policy determines that the MN-HA Key must be 619 encrypted and no security association is known to the home agent, the 620 AAAH MUST send the HAR to the AAAF in foreign network 1, which 621 originally assigned the HA in foreign network 1, by including its 622 identity in the Destination-Host AVP. 624 When the AAAF receives a HAA, the AAAF will forward the HAA back to 625 the AAAH. If successful, the HAA MUST include the MIP-Home-Agent- 626 Address and the MIP-Mobile-Node-Address AVPs. The AAAH will then send 627 back an AMA to the AAAF in foreign network 2. 629 If the old Foreign Network does not permit the use of its Home Agent 630 when the Mobile Node moves to a new foreign network, the AAAH or AAAF 631 MUST return an AMA with the Result-Code AVP set to 632 DIAMETER_ERROR_HA_NOT_AVAILABLE. Upon receipt of this error, the 633 Foreign Agent MUST issue a Mobile IP Registration Reply to the Mobile 634 Node with an appropriate error. The Mobile Node MAY attempt to 635 request that a new Home Agent and Address be allocated. When the AAAH 636 transmits such an error, it MUST issue a Diameter Abort-Session- 637 Request message to the Home Agent to enable it to release any 638 resources. 640 1.5 Co-located Mobile Node 642 In the event that a Mobile Node registers with the Home Agent as a 643 co-located Mobile Node, there is no Foreign Agent involved. 644 Therefore, when the Home Agent receives the Registration Request, an 645 AMR message is sent to the local AAAH server, with the Co-Located- 646 Mobile-Node bit set in the MIP-Feature-Vector AVP. The Home Agent 647 also includes the Accounting-Multi-Session-Id AVP in the AMR sent to 648 the AAAH, as the AAAH may find this a useful piece of session-state 649 or log entry information. 651 Home 652 Realm 653 +--------+ 654 | AAAH | 655 | | 656 | server | 657 +--------+ 658 ^ | 659 | | 660 AMR | | AMA 661 | v 662 +--------+ +---------+ 663 | Mobile | Registration | Home | 664 | Node |-------------->| Agent | 665 +--------+ Request +---------+ 666 Figure 8: Co-located Mobile Node 668 If the MN-HA-Key-Requested bit was set in the AMR message from the 669 Home Agent, the Home Agent and Mobile Node's session keys would be 670 present in the AMA message. 672 1.6 Diameter Session Termination 674 A Foreign and Home Agent following this specification MAY expect 675 their respective Diameter servers to maintain session state 676 information for each mobile node in their networks. In order for the 677 Diameter Server to release any resources allocated to a specific 678 mobile node, the mobility agents MUST send a Session-Termination- 679 Request (STR) to the Diameter server that authorized the service. The 680 Session-Termination-Request (STR) MUST be issued by the mobility 681 agents if the Authorization Lifetime has expired and no subsequent 682 MIP registration request have been received. 684 The Home Diameter server SHOULD only deallocate all resources after 685 the STR is received from the Home Agent. This ensures that a Mobile 686 Node that moves from one Foreign Agent to another (hand-off) does not 687 cause the Home Diameter Server to free all resources for the Mobile 688 Node. 690 In the event that the AAAF wishes to terminate a session, its Abort- 691 Session-Request (ASR) [DIAMBASE] message SHOULD be sent to the FA. 692 Similarly, the AAAH SHOULD send its message to the Home Agent. 694 1.7 Advertising application support 696 Diameter nodes conforming to this specification MAY advertise support 697 by including the value of four (4) in the Auth-Application-Id or the 698 Acct-Application-Id AVP of the Capabilities-Exchange-Request and 699 Capabilities-Exchange-Answer command [DIAMBASE]. 701 1.8 Fast Handoff support 703 This application requires that foreign agents issue an AMR upon 704 receipt of the first registration message from a mobile node, 705 regardless of the fact that the mobile node MAY have been previously 706 authorized to another foreign agent. 708 The Mobile IP Working Group is currently investigating fast handoff 709 proposals, and the Seamoby WG is looking at creating a protocol that 710 would allow AAA state information to be exchange between foreign 711 agents during a handoff. These proposals MAY allow future 712 enhancements to the Diameter protocol, in order to reduce the amount 713 of Diameter exchanges required during a handoff. 715 2.0 Command-Code Values 717 This section defines Command-Code [DIAMBASE] values that MUST be 718 supported by all Diameter implementations conforming to this 719 specification. The following Command Codes are defined in this 720 specification: 722 Command-Name Abbreviation Code Section 723 ----------------------------------------------------------- 724 AA-Mobile-Node-Answer AMA 260 2.2 725 AA-Mobile-Node-Request AMR 260 2.1 726 Home-Agent-MIP-Answer HAA 262 2.4 727 Home-Agent-MIP-Request HAR 262 2.3 729 2.1 AA-Mobile-Node-Request 731 The AA-Mobile-Node-Request (AMR), indicated by the Command-Code field 732 set to 260 and the 'R' bit set in the Command Flags field, is sent by 733 an attendant, acting as a Diameter client, to a server in order to 734 request the authentication and authorization of a Mobile Node. The 735 Foreign Agent (or Home Agent in the case of a co-located Mobile Node) 736 uses information found in the Registration Request to construct the 737 following AVPs that are to be included as part of the AMR: 739 home address (MIP-Mobile-Node-Address AVP) 740 home agent address (MIP-Home-Agent-Address AVP) 741 mobile node NAI (User-Name AVP [DIAMBASE]) 742 MN-HA Key Request (MIP-Feature-Vector AVP) 743 MN-FA Key Request (MIP-Feature-Vector AVP) 744 MN-AAA Authentication Extension (MIP-MN-AAA-Auth AVP) 745 Foreign Agent Challenge Extension (MIP-FA-Challenge AVP) 746 home agent NAI (MIP-Home-Agent-Host AVP) 747 home AAA server NAI (Destination-Host AVP [DIAMBASE]) 749 If the mobile node's home address is zero, the foreign or home agent 750 MUST NOT include a MIP-Mobile-Node-Address AVP in the AMR. If the 751 home agent address is zero or all ones, the MIP-Home-Agent-Address 752 AVP MUST NOT be present in the AMR. 754 If a Foreign Agent is used in a visited network, the AAAF MAY set the 755 Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP in 756 the AMR message to indicate that it is willing to assign a Home Agent 757 in the visited realm. 759 If the mobile node's home address is all ones, the foreign or home 760 agent MUST include a MIP-Mobile-Node-Address AVP, set to all ones. 762 If the mobile node includes the home agent NAI and the home AAA 763 server NAI [AAANAI], the foreign agent MUST include the MIP-Home- 764 Agent-Host AVP and the Destination-Host AVP in the AMR. 766 Message Format 768 ::= < Diameter Header: 260, REQ, PXY > 769 < Session-ID > 770 { Auth-Application-Id } 771 { User-Name } 772 { Destination-Realm } 773 { Origin-Host } 774 { Origin-Realm } 775 { MIP-Reg-Request } 776 { MIP-MN-AAA-Auth } 777 [ Destination-Host ] 778 [ Origin-State-Id ] 779 [ MIP-Mobile-Node-Address ] 780 [ MIP-Home-Agent-Address ] 781 [ MIP-Feature-Vector ] 782 [ MIP-Originating-Foreign-AAA ] 783 [ Authorization-Lifetime ] 784 [ Auth-Grace-Period ] 785 [ Auth-Session-State ] 786 [ MIP-FA-Challenge ] 787 [ MIP-Candidate-Home-Agent-Host ] 788 * [ AVP ] 789 * [ Proxy-Info ] 790 * [ Route-Record ] 792 2.2 AA-Mobile-Node-Answer 794 The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code field 795 set to 260 and the 'R' bit cleared in the Command Flags field, is 796 sent by the AAAH in response to the AA-Mobile-Node-Request message. 797 The User-Name MAY be included in the AMA if present in the AMR. The 798 Result-Code AVP MAY contain one of the values defined in section 3.0, 799 in addition to the values defined in [DIAMBASE]. 801 An AMA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST 802 include the MIP-Home-Agent-Address AVP, MUST include the MIP-Home- 803 Mobile-Node-Address AVP, and includes the MIP-Reg-Reply AVP if and 804 only if the Co-Located-Mobile-Node bit was not set in the MIP- 805 Feature-Vector AVP. The MIP-Home-Agent-Address AVP contains the Home 806 Agent assigned to the Mobile Node, while the MIP-Mobile-Node-Address 807 AVP contains the home address that was assigned. The AMA message MUST 808 contain the MIP-FA-to-HA-Key, MIP-FA-to-MN-Key if they were requested 809 in the AMR, and they were present in the HAR. The MIP-MN-to-HA-Key 810 and MIP-HA-to-MN-Key AVPs MUST be present if the session keys were 811 requested in the AMR, and the Co-Located-Mobile-Node bit was set in 812 the MIP-Feature-Vector AVP. 814 An AMA message with the Result-Code AVP set to 815 DIAMETER_LIMITED_SUCCESS MAY include the MIP-Home-Agent-Address AVP 816 if a dynamically assigned home agent was requested by the mobile 817 node. Upon receipt of this result code, the foreign agent MUST issue 818 the Registration Request to the Home Agent in the manner described in 819 [MOBILEIP]. 821 An AMA message with the Result-Code set to DIAMETER_MULTI_ROUND_AUTH 822 MAY include mobile node session key AVPs (see Section 6.1) such as 823 the MIP-MN-to-FA-Key AVP and the MIP-MN-to-HA-Key AVP. If such an AVP 824 is present in the AMA message, the foreign agent MUST include the 825 corresponding Mobile IP key distribution extension in the 826 Registration Reply it sends to the mobile node. This is to support 827 multi-roundtrip authentication mechanisms. 829 Message Format 831 ::= < Diameter Header: 260, PXY > 832 < Session-Id > 833 { Auth-Application-Id } 834 { Result-Code } 835 { Origin-Host } 836 { Origin-Realm } 837 [ User-Name ] 838 [ Accounting-Multi-Session-Id ] 839 [ Authorization-Lifetime ] 840 [ Auth-Grace-Period ] 841 [ Auth-Session-State ] 842 [ Error-Message ] 843 [ Error-Reporting-Host ] 844 [ Re-Auth-Request-Type ] 845 [ MIP-Feature-Vector ] 846 [ MIP-Reg-Reply ] 847 [ MIP-MN-to-FA-Key ] 848 [ MIP-MN-to-HA-Key ] 849 [ MIP-FA-to-MN-Key ] 850 [ MIP-FA-to-HA-Key ] 851 [ MIP-HA-to-MN-Key ] 852 [ MIP-HA-to-FA-Key ] 853 [ MIP-Key-Lifetime ] 854 [ MIP-Home-Agent-Address ] 855 [ MIP-Mobile-Node-Address ] 856 * [ MIP-Filter-Rule ] 857 [ Origin-State-Id ] 858 * [ AVP ] 859 * [ Proxy-Info ] 861 2.3 Home-Agent-MIP-Request 863 The Home-Agent-MIP-Request (HAR), indicated by the Command-Code field 864 set to 262 and the 'R' bit set in the Command Flags field, is sent by 865 the AAA to the Home Agent. If the Home Agent is to be assigned in a 866 foreign network, the HAR is issued by the AAAH and forwarded by the 867 AAAF. If the HAR message does not include a MIP-Mobile-Node-Address 868 AVP, and the Registration Request has 0.0.0.0 for the home address, 869 and the HAR is successfully processed, the Home Agent MUST allocate 870 one such address to the mobile node. If the home agent's local AAA 871 server allocates the mobile node's home address, it MUST include the 872 assigned address in an MIP-Mobile-Node-Address AVP. 874 When session keys are requested for use by the mobile node (see 875 section 5.0), the AAAH MUST create them and include them in the HAR 876 message. When a Foreign-Home session key is requested, it will be 877 created and distributed by the AAA server in the same realm as the 878 home agent. 880 Message Format 882 ::= < Diameter Header: 262, REQ, PXY > 883 < Session-Id > 884 { Auth-Application-Id } 885 { Authorization-Lifetime } 886 { Auth-Grace-Period } 887 { Auth-Session-State } 888 { MIP-Reg-Request } 889 { Origin-Host } 890 { Origin-Realm } 891 { User-Name } 892 { Destination-Realm } 893 { MIP-Feature-Vector } 894 [ Destination-Host ] 895 [ MIP-MN-to-HA-Key ] 896 [ MIP-MN-to-FA-Key ] 897 [ MIP-HA-to-MN-Key ] 898 [ MIP-HA-to-FA-Key ] 899 [ MIP-Key-Lifetime ] 900 [ MIP-Foreign-Agent-Host ] 901 [ MIP-Originating-Foreign-AAA ] 902 [ MIP-Mobile-Node-Address ] 903 [ MIP-Home-Agent-Address ] 904 * [ MIP-Filter-Rule ] 905 [ Origin-State-Id ] 906 * [ AVP ] 907 * [ Proxy-Info ] 908 * [ Route-Record ] 910 2.4 Home-Agent-MIP-Answer 912 The Home-Agent-MIP-Answer (HAA), indicated by the Command-Code field 913 set to 262 and the 'R' bit cleared in the Command Flags field, is 914 sent by the Home Agent to its local AAA server in response to a Home- 915 Agent-MIP-Request. The User-Name MAY be included in the HAA if 916 present in the HAR. If the home agent allocated a home address for 917 the Mobile Node, the address MUST be included in the MIP-Mobile-Node- 918 Address AVP. The Result-Code AVP MAY contain one of the values 919 defined in section 3.0 instead of the values defined in [DIAMBASE]. 921 Message Format 923 ::= < Diameter Header: 262, PXY > 924 < Session-Id > 925 { Auth-Application-Id } 926 { Result-Code } 927 { Origin-Host } 928 { Origin-Realm } 929 { Accounting-Multi-Session-Id } 930 [ User-Name ] 931 [ Error-Reporting-Host ] 932 [ Error-Message ] 933 [ MIP-Reg-Reply ] 934 [ MIP-Home-Agent-Address ] 935 [ MIP-Mobile-Node-Address ] 936 [ MIP-FA-to-HA-SPI ] 937 [ MIP-FA-to-MN-SPI ] 938 [ Origin-State-Id ] 939 * [ AVP ] 940 * [ Proxy-Info ] 942 3.0 Result-Code AVP Values 944 This section defines new Result-Code [DIAMBASE] values that MUST be 945 supported by all Diameter implementations that conform to this 946 specification. 948 3.1 Transient Failures 950 Errors that fall within the transient failures category are used to 951 inform a peer that the request could not be satisfied at the time it 952 was received, but MAY be able to satisfy the request in the future. 954 DIAMETER_ERROR_MIP_REPLY_FAILURE 4005 955 This error code is used by the Home Agent when processing of 956 the Registration Request has failed. 958 DIAMETER_ERROR_HA_NOT_AVAILABLE 4006 959 This error code is used to inform the Foreign Agent that the 960 requested Home Agent cannot be assigned to the Mobile Node at 961 this time. The Foreign Agent MUST return a Mobile IP 962 Registration Reply to the Mobile Node with an appropriate error 963 code. 965 DIAMETER_ERROR_BAD_KEY 4007 966 This error code is used by the Home Agent to indicate to the 967 local Diameter server that the key generated is invalid. 969 3.2 Permanent Failures 971 Errors that fall within the permanent failures category are used to 972 inform the peer that the request failed, and should not be attempted 973 again. 975 DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE 5024 976 This error is used by the AAAF to inform the AAAH that 977 allocation of a Home Agent in the Foreign Domain is not 978 permitted at this time. 980 DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION 5025 981 This error is used by the AAAF / AAAH to inform that the 982 requested mobile IP session keys could not be encrypted with 983 the CMS strong security application and therefore failed. 985 4.0 Mandatory AVPs 987 The following table describes the Diameter AVPs defined in the Mobile 988 IP application, their AVP Code values, types, possible flag values 989 and whether the AVP MAY be encrypted. 991 Due to space constraints, the short form IPFiltrRule is used to 992 represent IPFilterRule and DiamIdent is used to represent 993 DiameterIdentity. 995 +---------------------+ 996 | AVP Flag rules | 997 |----+-----+----+-----|----+ 998 AVP Section | | |SHLD| MUST|MAY | 999 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 1000 -----------------------------------------|----+-----+----+-----|----| 1001 MIP-Filter-Rule 342 4.9 IPFiltrRule| M | P | | V | Y | 1002 MIP-Auth-Input- 338 4.6.2 Unsigned32 | M | P | | V | Y | 1003 Data-Length | | | | | | 1004 MIP- 339 4.6.3 Unsigned32 | M | P | | V | Y | 1005 Authenticator-Length | | | | | | 1006 MIP- 340 4.6.4 Unsigned32 | M | P | | V | Y | 1007 Authenticator-Offset | | | | | | 1008 MIP-Candidate- 336 4.10 DiamIdent | M | P | | V | N | 1009 Home-Agent-Host | | | | | | 1010 MIP-Home-Agent- 348 4.12 DiamIdent | M | P | | V | N | 1011 Host | | | | | | 1012 MIP-FA-Challenge 344 4.7 OctetString| M | P | | V | Y | 1013 MIP-Feature- 337 4.5 Unsigned32 | M | P | | V | Y | 1014 Vector | | | | | | 1015 MIP-Foreign- 330 4.8 DiamIdent | M | P | | V | Y | 1016 Agent-Host | | | | | | 1017 MIP-Home-Agent- 334 4.4 IPAddress | M | P | | V | Y | 1018 Address | | | | | | 1019 MIP-MN-AAA-Auth 322 4.6 Grouped | M | P | | V | Y | 1020 MIP-MN-AAA-SPI 341 4.6.1 Unsigned32 | M | P | | V | Y | 1021 MIP-Mobile-Node- 333 4.3 IPAddress | M | P | | V | Y | 1022 Address | | | | | | 1023 MIP-Reg-Request 320 4.1 OctetString| M | P | | V | Y | 1024 MIP-Reg-Reply 321 4.2 OctetString| M | P | | V | Y | 1025 MIP-Originating- 347 4.11 Grouped | M | P | | V | Y | 1026 Foreign-AAA | | | | | | 1028 4.1 MIP-Reg-Request AVP 1030 The MIP-Reg-Request AVP (AVP Code 320) is of type OctetString and 1031 contains the Mobile IP Registration Request [MOBILEIP] sent by the 1032 Mobile Node to the Foreign Agent. 1034 4.2 MIP-Reg-Reply AVP 1036 The MIP-Reg-Reply AVP (AVP Code 321) is of type OctetString and 1037 contains the Mobile IP Registration Reply [MOBILEIP] sent by the Home 1038 Agent to the Foreign Agent. 1040 4.3 MIP-Mobile-Node-Address AVP 1042 The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type IPAddress 1043 and contains the Mobile Node's Home Address. 1045 4.4 MIP-Home-Agent-Address AVP 1047 The MIP-Home-Agent-Addess AVP (AVP Code 334) is of type IPAddress and 1048 contains the Mobile Node's Home Agent Address. 1050 4.5 MIP-Feature-Vector AVP 1052 The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and 1053 is added with flag values set by the Foreign Agent or by the AAAF 1054 owned by the same administrative domain as the Foreign Agent. The 1055 Foreign Agent SHOULD include MIP-Feature-Vector AVP within the AMR 1056 message it sends to the AAAF. 1058 Flag values currently defined include: 1059 1 Mobile-Node-Home-Address-Requested 1060 2 Home-Address-Allocatable-Only-in-Home-Realm 1061 4 Home-Agent-Requested 1062 8 Foreign-Home-Agent-Available 1063 16 MN-HA-Key-Request 1064 32 MN-FA-Key-Request 1065 64 FA-HA-Key-Request 1066 128 Home-Agent-In-Foreign-Network 1067 256 Co-Located-Mobile-Node 1069 The flags are set according to the following rules. 1071 If the mobile node includes a valid home address (i.e., not equal to 1072 0.0.0.0 or 255.255.255.255) in its Registration Request, the Foreign 1073 Agent zeroes the Mobile-Node-Home-Address-Requested flag in the MIP- 1074 Feature-Vector AVP. 1076 If the mobile node sets the home address field equal to 0.0.0.0 in 1077 its Registration Request, the Foreign Agent sets the Mobile-Node- 1078 Home-Address-Requested flag to one. 1080 If the mobile node sets the home agent field equal to 255.255.255.255 1081 in its Registration Request, the Foreign Agent sets both the Home- 1082 Agent-Requested flag and the Home-Address-Allocatable-Only-in-Home- 1083 Realm flag to one in the MIP-Feature-Vector AVP. 1085 If the mobile node sets the home agent field equal to 0.0.0.0 in its 1086 Registration Request, the Foreign Agent sets the Home-Agent-Requested 1087 flag to one, and zeroes the Home-Address-Allocatable-Only-in-Home- 1088 Realm flag in the MIP-Feature-Vector AVP. 1090 Whenever the Foreign Agent sets either the Mobile-Node-Home-Address- 1091 Requested flag or the Home-Agent-Requested flag to one, it MUST set 1092 the MN-HA-Key-Request flag to one. The MN-HA-Key-Request flag is also 1093 set to one if the mobile node includes a Generalized MN-HA Key 1094 Request [MIPKEYS] extension, with the subtype set to AAA. 1096 If the mobile node includes a Generalized MN-FA Key Request [MIPKEYS] 1097 extension with the AAA subtype in its Registration Request, the 1098 Foreign Agent sets the MN-FA-Key-Request flag to one in the MIP- 1099 Feature-Vector AVP. 1101 If the mobile node requests a home agent in the foreign network 1102 either by setting the home address field to all ones, or by 1103 specifying a home agent in the foreign network, and the AAAF 1104 authorizes the request, the AAAF MUST set the Home-Agent-In-Foreign- 1105 Network bit to one. 1107 If the Home Agent receives a Registration Request from the Mobile 1108 Node indicating that the MN is acting as a Co-Located Mobile Node, 1109 the Home Agent sets the Co-Located-Mobile-Node bit to one. 1111 If the foreign agent's local policy allows it to receive AAA session 1112 keys, and it does not have any existing FA-HA key with the home 1113 agent, the foreign agent MAY set the FA-HA-Key-Request flag 1115 The Foreign Agent MUST NOT set the Foreign-Home-Agent-Available, and 1116 Home-Agent-In-Foreign-Network flag to one. 1118 When the AAAF receives the AMR message, it MUST first verify that the 1119 sender was an authorized Foreign Agent. The AAAF then takes any 1120 actions indicated by the settings of the MIP-Feature-Vector AVP 1121 flags. The AAAF then MAY set additional flags.Only the AAAF may set 1122 the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network 1123 flags to one. This is done according to local administrative policy. 1124 When the AAAF has finished setting additional flags according to its 1125 local policy, then the AAAF transmits the AMR with the possibly 1126 modified MIP-Feature-Vector AVP to the AAAH. 1128 4.6 MIP-MN-AAA-Auth AVP 1130 The MN-AAA-Auth AVP (AVP Code 322) is of type Grouped and contains 1131 some ancillary data to simplify processing of the authentication data 1132 in the Mobile IP Registration Request [MOBILEIP] by the target AAA 1133 server. Its value has the following ABNF grammar: 1135 MIP-MN-AAA-Auth ::= < AVP Header: 322 > 1136 { MIP-MN-AAA-SPI } 1137 { MIP-Auth-Input-Data-Length } 1138 { MIP-Authenticator-Length } 1139 { MIP-Authenticator-Offset } 1140 * [ AVP ] 1142 4.6.1 MIP-MN-AAA-SPI AVP 1143 The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and 1144 indicates the algorithm by which the targeted AAA server (AAAH) 1145 should attempt to validate the Authenticator computed by the mobile 1146 node over the Registration Request data. 1148 4.6.2 MIP-Auth-Input-Data-Length AVP 1150 The MIP-Auth-Input-Data-Length AVP (AVP Code 338) is of type 1151 Unsigned32 and contains the length, in bytes, of the Registration 1152 Request data (data portion of MIP-Reg-Request AVP) that should be 1153 used as input to the algorithm (indicated by the MN-AAA-SPI AVP) used 1154 to determine whether the Authenticator Data supplied by the Mobile 1155 Node is valid. 1157 4.6.3 MIP-Authenticator-Length AVP 1159 The MIP-Authenticator-Length AVP (AVP Code 339) is of type Unsigned32 1160 and contains the length of the authenticator to be validated by the 1161 targeted AAA server (i.e., AAAH). 1163 4.6.4 MIP-Authenticator-Offset AVP 1165 The MIP-Authenticator-Offset AVP (AVP Code 340) is of type Unsigned32 1166 and contains the offset into the Registration Request Data, of the 1167 authenticator to be validated by the targeted AAA server (i.e., 1168 AAAH). 1170 4.7 MIP-FA-Challenge 1171 The MIP-FA-Challenge AVP (AVP Code 344) is of type OctetString and 1172 contains the challenge advertised by the Foreign Agent to the Mobile 1173 Node. This AVP MUST be present in the AMR if the Mobile Node used the 1174 RADIUS-style MN-AAA computation algorithm. 1176 4.8 MIP-Foreign-Agent-Host AVP 1178 The MIP-Foreign-Agent-Host AVP (AVP Code 330) is of type 1179 DiameterIdentity and contains the identity of the foreign agent. This 1180 AVP is copied from the value of the Origin-Host AVP in the AMR. 1182 4.9 MIP-Filter-Rule AVP 1184 The MIP-Filter-Rule AVP (AVP Code 342) is of type IPFilterRule, and 1185 provides filter rules that need to be configured on the Foreign or 1186 Home Agent for the user. One or more such AVPs MAY be present in an 1187 authorization response. 1189 4.10 MIP-Candidate-Home-Agent-Host 1191 The MIP-Candidate-Home-Agent-Host AVP (AVP Code 336) is of type 1192 DiameterIdentity and contains the identity of a home agent in the 1193 foreign network that the AAAF proposes be dynamically assigned to the 1194 mobile node. 1196 4.11 MIP-Originating-Foreign-AAA AVP 1198 The MIP-Originating-Foreign-AAA AVP (AVP Code 347) if of type 1199 Grouped, and contains the identity of the AAAF, which issues the AMR 1200 to the AAAH. The MIP- Originating-Foreign-AAA AVP MUST only be used 1201 in cases when the home agent is or may be allocated in a foreign 1202 domain. If present in the AMR, the AAAH MUST copy the MIP- 1203 Originating-Foreign-AAA AVP into the HAR. 1205 MIP-Originating-Foreign-AAA ::= < AVP Header: 347 > 1206 { Origin-Realm } 1207 { Origin-Host } 1208 * [ AVP ] 1210 4.12 MIP-Home-Agent-Host AVP 1212 The MIP-Home-Agent-Host AVP (AVP Code 348) if of type Grouped, and 1213 contains the identity of the assigned Home Agent. If present in the 1214 AMR, the AAAH MUST copy the MIP-Home-Agent-Host AVP into the HAR. 1216 MIP-Home-Agent-Host ::= < AVP Header: 348 > 1217 { Destination-Realm } 1218 { Destination-Host } 1219 * [ AVP ] 1221 5.0 Key Distribution Center 1223 The mobile node and mobility agents use session keys to compute 1224 authentication extensions applied to registration messages, as 1225 defined in [MOBILEIP]: Mobile-Foreign, Foreign-Home and Mobile-Home. 1226 If session keys are requested the AAA server(s) MUST return the key 1227 material after the Mobile Node is successfully authenticated and 1228 authorized. 1230 The SPI values are used as key identifiers, meaning that each session 1231 key has its own SPI value; nodes that share a key also share an SPI. 1232 The Mobile Node proposes SPIs for use in computing the Mobile-Foreign 1233 and Mobile-Home authentication extensions, via the Mobile IP AAA Key 1234 Request extensions [MIPKEYS], while the Home Agent allocates the 1235 Mobile-Foreign, Mobile-Home and Foreign-Home SPIs. 1237 Once the session keys have been distributed, subsequent Mobile IP 1238 registrations need not invoke the AAA infrastructure until the keys 1239 expire. These registrations MUST include the Mobile-Home 1240 authentication extension. In addition, subsequent registrations MUST 1241 also include Mobile-Foreign authentication extension if the Mobile- 1242 Foreign key was generated and distributed by AAA; similarly for 1243 subsequent use of the Foreign-Home authentication extensions. 1245 5.1 Authorization Lifetime vs. MIP Key Lifetime 1247 The Diameter Mobile IP application makes use of two timers - the 1248 Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP. 1250 The Authorization-Lifetime contains the number of seconds before the 1251 Mobile Node must issue a subsequent MIP registration request. The 1252 content of the Authorization-Lifetime AVP corresponds to the Lifetime 1253 field in the MIP header [MOBILEIP]. 1255 The MIP-Key-Lifetime AVP contains the number of seconds before 1256 session keys destined for the Mobility Agents and the Mobile Node 1257 expire. A value of zero indicates infinity (no timeout). If not zero, 1258 the value of the MIP-Key-Lifetime AVP MUST be at least equal to the 1259 value in the Authorization Lifetime AVP. 1261 5.2 Key Material vs. Session Key 1263 Each session key that is generated by the AAAH will generally be 1264 distributed to two parties; for instance, a Mobile-Foreign is sent to 1265 both the mobile node and the foreign agent. 1267 The key sent to the mobile node is always in the form of key 1268 material, which the AAAH does by generating a random [RANDOM] value 1269 of at least 64 bits. The random value is used by the mobile node to 1270 create the actual session key. The following is an example of a 1271 session creation procedure, using MD5 as the hashing algorithm. 1272 Additional algorithms are supported, and listed in [MIPKEYS]. 1274 MD5(AAA-Key | key material | node-address | AAA-Key) 1276 Where: 1278 - AAA-Key is the long term secret shared between the mobile 1279 node and the AAAH. 1280 - Key material is a random [RANDOM] value of at least 64 bits. 1281 - node-address is the mobile node's identity. This is the 1282 contents of the MIP-Mobile-Node-Address AVP, unless the value 1283 of the AVP is all zero or ones, in which case of value of the 1284 User-Name AVP is used instead. 1286 The AAAH then generates the session key, which is destined for the 1287 mobility agent, in this case the foreign agent, by following the 1288 above procedures. It is important that the hashing algorithm used by 1289 the mobile node to construct the session key is the same as the one 1290 used by the AAAH in the session key generation procedure. The AAAH 1291 therefore indicates the algorithm used along with the key material. 1292 The session keys destined for mobility agents may be encoded using 1293 the security association available between the AAA server and the 1294 agents (e.g. IPSec, TLS, CMS). 1296 The Foreign-Home session key is shared between two mobility agents: 1297 the FA and HA. Since this key is not destined for the mobile node, 1298 there is no need to follow the session key generation procedures 1299 detailed above. Instead, the AAAH generates a random [RANDOM] value 1300 of at least 64 bits for use as the Foreign-Home session key. 1302 See sections 6.0 for details about the format of the AVPs used to 1303 transport the session keys. 1305 5.3 Distributing the Mobile-Home Session Key 1307 If the mobile node does not have a Mobile-Home session key, then the 1308 AAAH is likely to be the only entity trusted that is available to the 1309 mobile node. Thus, the AAAH has to generate the Mobile-Home session 1310 key, and encode it for eventual consumption by the mobile node and 1311 home agent. 1313 If the home agent is in the home realm, then the AAAH can directly 1314 encode the Mobile-Home session key into a MIP-HA-to-MN-Key AVP and 1315 include that AVP in the HAR message for delivery to the home agent. 1317 If, on the other hand, the home agent is to be allocated in the 1318 visited realm, the AAAH transmits the HAR to the foreign home agent, 1319 where, prior to delivery to the home agent, it is perused by the AAAF 1320 hosting the home agent. If the session key needs to be encrypted the 1321 AAAH will encrypt the MIP-HA-to-MN Key AVP and the MIP-FA-to-MN AVP 1322 with help of CMS security application [CMS] using the security 1323 association with the AAAF associated with the home agent. If no 1324 security association exists between the AAAH and the AAAF associated 1325 with the home agent, the AAAH will check if a security association 1326 can be established. If no security association exists and cannot be 1327 created, the AAAH MUST return a Result-Code AVP with 1328 DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION. 1330 The AAAH also has to arrange for the key to be delivered to the 1331 mobile node. Unfortunately, the AAA server only knows about Diameter 1332 messages and AVPs, and the mobile node only knows about Mobile IP 1333 messages and extensions [MOBILEIP]. For this purpose, AAAH encodes 1334 the Mobile-Home session key material into a MIP-MN-to-HA-Key AVP, 1335 using its security association with the mobile node, which is added 1336 to the HAR message, and delivered either to a local home agent, or to 1337 the AAAF in the case where the home agent is in the visited network. 1338 The AAAH has to rely on the home agent (that also understands 1339 Diameter) to transfer the keying information into a Mobile IP 1340 Generalized MN-HA Key Reply extension [MIPKEYS] in the Registration 1341 Reply message, using the SPI proposed by the Mobile Node in the MN-HA 1342 Key Request From AAA Subtype extension. The home agent can format the 1343 Reply message and extensions correctly for eventual delivery to the 1344 mobile node. The resulting Registration Reply is added to the HAA's 1345 MIP-Reg-Reply AVP. 1347 After the HAA message is parsed by the AAAH, and transformed into an 1348 AMA, the AMA message containing the MIP-Reg-Reply AVP will eventually 1349 be received by the the foreign agent. The foreign agent can then use 1350 that AVP to recreate a Registration Reply message, containing the 1351 Generalized MN-HA Key Reply extension, for delivery to the mobile 1352 node. 1354 In summary, the AAAH generates the Mobile-Home key material, which is 1355 added to the MIP-MN-to-HA-Key AVP. The key material is then used to 1356 compute the home agent's session key as specified in [MIPKEYS], which 1357 is then added to the MIP-HA-to-MN-Key AVP. These AVPs are delivered 1358 to a home agent by including them in a HAR message sent from either 1359 AAAH or AAAF. The home agent decodes the key for its own use. The 1360 home agent also copies the encoded key material from the MIP-MN-to- 1361 HA-Key AVP into a Generalized MN-HA Key Reply extension appended to 1362 the Mobile IP Registration Reply message. This Registration Reply 1363 message MUST also include the Mobile-Home authentication extension, 1364 created using the newly allocated Mobile-Home session key. The home 1365 agent then encodes the Registration Reply message and extensions into 1366 a MIP-Reg-Reply AVP included as part of the HAA message to be sent 1367 back to the AAA server. 1369 5.4 Distributing the Mobile-Foreign Session Key 1371 The Mobile-Foreign session key material is also generated by AAAH 1372 (upon request) and is added to the MIP-MN-to-FA-Key AVP, which is 1373 added to the HAR, and copied by the home agent into a Generalized MN- 1374 FA Key Reply Extension [MIPKEYS] to the Mobile IP Registration Reply 1375 message, using the SPI proposed by the Mobile Node in the MN-FA Key 1376 Request From AAA Subtype extension. Further, the home agent includes 1377 the SPI in the HAA's MIP-FA-to-MN-SPI AVP. The AAAH includes the 1378 session key in the MIP-FA-to-MN-Key AVP in the HAA, which contains 1379 the session key used by the foreign agent in the computation of the 1380 Mobile-Foreign authentication extension. 1382 If the MIP-FA-to-MN-Key AVP was present in the AMA, the foreign agent 1383 MUST include the Mobile-Foreign authentication extension in the 1384 Registration Reply, using the newly distributed key. 1386 5.5 Distributing the Foreign-Home Session Key 1388 If the home agent is in the home realm, then the AAAH has to generate 1389 the Foreign-Home session key. Otherwise, it is generated by the AAAF. 1391 5.5.1 Home Agent in the home network 1393 In the cases when the AAAH generates the Foreign-Home session key, 1394 the AAAH includes the session key in the MIP-HA-to-FA-Key AVP, and 1395 includes the AVP as part of the HAR message sent to the home agent. 1396 The corresponding session key and algorithm that is to be sent to the 1397 foreign agent is cached in the AAAH until the HAA is received. 1399 Upon receipt of the HAR, the home agent recovers the Foreign-Home 1400 session key, allocates an SPI to be used with the key. The allocated 1401 SPI is included in the HAA's MIP-FA-to-HA SPI AVP. 1403 Upon receipt of the HAA, the AAAH adds the MIP-FA-to-HA Key AVP, 1404 using the SPI in the MIP-FA-to-HA-SPI, and includes the AVP in the 1405 AMA. 1407 5.5.2 Home Agent in foreign network 1409 In the cases when the AAAF generates the Foreign-Home session key 1410 (home agent in foreign domain), the AAAF will, upon receipt of the 1411 HAR message, generate the Foreign-Home session key and include the 1412 session key in the MIP-HA-to-FA-Key AVP as part of the HAR message 1413 forwarded to the home agent. The corresponding session key and 1414 algorithm that is to be sent to the foreign agent is cached in the 1415 AAAF until the HAA is received. 1417 Upon receipt of the HAA, the AAAF creates the MIP-FA-to-HA Key AVP, 1418 using the SPI in the MIP-FA-to-HA-SPI. The AAAF then checks if the 1419 Foreign-Home session key destined for the foreign agent needs to be 1420 encrypted. 1422 If the session key needs to be encrypted, the AAAF will check if a 1423 security association can be established, using the CMS security 1424 application [CMS] with the originating host found in the MIP- 1425 Originating-Foreign-AAA AVP. If the security association 1426 establishment is successful, the AAAF will encrypt the MIP-FA-to-HA 1427 Key AVP with help of the CMS security application [CMS] with the AAAF 1428 as originator and the recipient copied from the MIP-Originating- 1429 Foreign-AAA AVP. The encrypted FA-HA Key is included by the AAAF in 1430 the HAA destined for the AAAH. Otherwise, if the security association 1431 cannot be created, the AAAF MUST return a Result-Code AVP with 1432 DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION. 1434 If the session key does not need to be encrypted, the AAAF will add 1435 MIP-FA-to-HA Key to the HAA, upon reception from the HA and forward 1436 the HAA to the AAAH. 1438 In either case, the AAAF removes the MIP-FA-to-HA-SPI AVP from the 1439 HAA returned to the AAAH. 1441 Upon reception of the HAA, the AAAH MUST copy either the MIP-FA-to-HA 1442 Key AVP if present or the CMS-Encrypted-data AVP if present and not 1443 destined for the AAAH into the AMA. 1445 If a Foreign-Home session key was present in the AMA, the foreign 1446 agent MUST include the Mobile-Foreign authentication extension in the 1447 Registration Reply, using the newly distributed key. 1449 5.6 Key Distribution Example 1451 Figure 9 provides an example of subsequent Mobile IP message 1452 exchange, assuming that AAAH distributed session keys for all three 1453 MN-FA, FA-HA and HA-MN authentication extensions. 1455 Mobile Node Foreign Agent Home Agent 1456 ----------- ------------- ---------- 1458 Reg-Req(MN-HA-Auth, MN-FA-Auth)--------> 1460 Reg-Req(MN-HA-Auth, FA-HA-Auth)--------> 1462 <--------Reg-Rep(MN-HA-Auth, FA-HA-Auth) 1464 <--------Reg-Rep(MN-HA-Auth, MN-FA-Auth) 1466 Figure 9: Mobile IP Message Exchange 1468 6.0 Key Distribution Center (KDC) AVPs 1470 The Mobile-IP protocol defines a set of security associations shared 1471 between the Mobile Node, Foreign Agent and Home Agents. These three 1472 security associations (Mobile-Home, Mobile-Foreign, and Foreign- 1473 Home), can be dynamically created by the AAAH. This requires that the 1474 AAAH create Mobile-IP Session Keys, and that these keys be 1475 distributed to the three mobile entities, via the Diameter Protocol. 1476 AAA servers supporting the Diameter Mobile IP Application MUST 1477 implement the KDC AVPs defined in this document. In other words, AAA 1478 servers MUST be able to create three session keys: the Mobile-Home, 1479 Mobile-Foreign, and Foreign-Home keys. 1481 The names of the KDC AVPs indicate the two entities sharing the 1482 security association defined by the encrypted key material; the 1483 intended receiver of the AVP is the first named entity. So, for 1484 instance, the MIP-MN-to-HA-Key AVP contains the Mobile-Home key 1485 encrypted in a way that allows it to be recovered by the mobile node. 1487 If strong authentication and confidentiality of the session keys is 1488 required, it is recommended that the CMS security application [CMS] 1489 be used. 1491 The following table describes the Diameter AVPs defined in the Mobile 1492 IP application, their AVP Code values, types, possible flag values 1493 and whether the AVP MAY be encrypted. 1495 +---------------------+ 1496 | AVP Flag rules | 1497 |----+-----+----+-----|----+ 1498 AVP Section | | |SHLD| MUST|MAY | 1499 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 1500 -----------------------------------------|----+-----+----+-----|----| 1501 MIP-Algorithm- 345 6.8 Enumerated | M | P | | V | Y | 1502 Type | | | | | | 1503 MIP-FA-to-HA-Key 328 6.2 Grouped | M | P | | V | Y | 1504 MIP-FA-to-HA-SPI 318 6.11 Unsigned32 | M | P | | V | Y | 1505 MIP-FA-to-MN-Key 326 6.1 Grouped | M | P | | V | Y | 1506 MIP-FA-to-MN-SPI 319 6.10 Unsigned32 | M | P | | V | Y | 1507 MIP-HA-to-FA-Key 329 6.3 Grouped | M | P | | V | Y | 1508 MIP-HA-to-MN-Key 332 6.4 Grouped | M | P | | V | Y | 1509 MIP-Key-Lifetime 367 6.13 Unsigned32 | M | P | | V | Y | 1510 MIP-Key-Material 335 6.12 OctetString| M | P | | V | Y | 1511 MIP-MN-to-FA-Key 325 6.5 Grouped | M | P | | V | Y | 1512 MIP-MN-to-HA-Key 331 6.6 Grouped | M | P | | V | Y | 1513 MIP-Replay-Mode 346 6.9 Enumerated | M | P | | V | Y | 1514 MIP-Session-Key 343 6.7 OctetString| M | P | | V | Y | 1516 6.1 MIP-FA-to-MN-Key AVP 1518 The MIP-FA-to-MN-Key AVP (AVP Code 326) is of type Grouped, and 1519 contains the Foreign Agent's session key, which it shares with the 1520 Mobile Node. Its Data field has the following ABNF grammar: 1522 MIP-FA-to-MN-Key ::= < AVP Header: 326 > 1523 { MIP-FA-to-MN-SPI } 1524 { MIP-Algorithm-Type } 1525 { MIP-Session-Key } 1526 * [ AVP ] 1528 6.2 MIP-FA-to-HA-Key AVP 1530 The MIP-FA-to-HA-Key AVP (AVP Code 328) is of type Grouped, and 1531 contains the Foreign Agent's session key, which it shares with the 1532 Home Agent. Its Data field has the following ABNF grammar: 1534 MIP-FA-to-HA-Key ::= < AVP Header: 328 > 1535 { MIP-FA-to-HA-SPI } 1536 { MIP-Algorithm-Type } 1537 { MIP-Session-Key } 1538 * [ AVP ] 1540 6.3 MIP-HA-to-FA-Key AVP 1542 The MIP-HA-to-FA-Key AVP (AVP Code 329) is of type Grouped, and 1543 contains the Home Agent's session key, which it shares with the 1544 Foreign Agent. Its Data field has the following ABNF grammar: 1545 MIP-HA-to-FA-Key ::= < AVP Header: 329 > 1546 { MIP-Algorithm-Type } 1547 { MIP-Session-Key } 1548 * [ AVP ] 1550 6.4 MIP-HA-to-MN-Key AVP 1552 The MIP-HA-to-MN-Key AVP (AVP Code 332) is of type Grouped, and 1553 contains the Home Agent's session key, which it shares with the 1554 Mobile Node. Its Data field has the following ABNF grammar: 1556 MIP-HA-to-MN-Key ::= < AVP Header: 332 > 1557 { MIP-Algorithm-Type } 1558 { MIP-Replay-Mode } 1559 { MIP-Session-Key } 1560 * [ AVP ] 1562 6.5 MIP-MN-to-FA-Key AVP 1564 The MIP-MN-to-FA-Key AVP (AVP Code 325) is of type Grouped, and 1565 contains the Mobile Node's key material, which it uses to derive the 1566 session key it shares with the Foreign Agent. The Home Agent uses 1567 this AVP in the construction of the Mobile IP "Unsolicted MN-FA Key 1568 from AAA Subtype" extension [MIPKEYS]. The SPI in the extension's FA 1569 SPI field is allocated by the Home Agent, but it SHOULD take into 1570 consideration the SPI requested by the Mobile Node in the "MN-FA Key 1571 Request From AAA Subtype" extension. 1573 MIP-MN-to-FA-Key ::= < AVP Header: 325 > 1574 { MIP-Algorithm-Type } 1575 { MIP-Key-Material } 1576 { MIP-MN-AAA-SPI } 1577 * [ AVP ] 1579 6.6 MIP-MN-to-HA-Key AVP 1581 The MIP-MN-to-HA-Key AVP (AVP Code 331) is of type Grouped, and 1582 contains the Mobile Node's key material, which it uses to derive the 1583 session key it shares with the Home Agent. The Home Agent uses this 1584 AVP in the construction of the Mobile IP "Unsolicted MN-HA Key from 1585 AAA Subtype" extension [MIPKEYS]. The SPI in the extension's HA SPI 1586 field is allocated by the Home Agent, but it SHOULD take into 1587 consideration the SPI requested by the Mobile Node in the "MN-HA Key 1588 Request From AAA Subtype" extension. 1590 MIP-MN-to-HA-Key ::= < AVP Header: 331 > 1591 { MIP-Algorithm-Type } 1592 { MIP-Replay-Mode } 1593 { MIP-Key-Material } 1594 { MIP-MN-AAA-SPI } 1595 * [ AVP ] 1597 6.7 MIP-Session-Key AVP 1599 The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and 1600 contains the Session Key to be used between two Mobile IP entities. 1602 6.8 MIP-Algorithm-Type AVP 1604 The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated, and 1605 contains the Algorithm identifier used to generate the associated 1606 Mobile IP authentication extension. The following values are 1607 currently defined: 1609 1 Prefix+Suffix MD5 [MOBILEIP] 1610 2 HMAC-MD5 [HMAC] 1611 3 HMAC-SHA-1 [HMAC] 1613 6.9 MIP-Replay-Mode AVP 1615 The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and 1616 contains the replay mode the Home Agent should use when 1617 authenticating the Mobile Node. 1619 The following values are supported (see [MOBILEIP] for more 1620 information): 1622 1 None 1623 2 Timestamps 1624 3 Nonces 1626 6.10 MIP-FA-to-MN-SPI AVP 1628 The MIP-FA-to-MN-SPI AVP (AVP Code 319) is of type Unsigned32, and 1629 contains the Security Parameter Index the Foreign Agent is to use to 1630 refer to the session key it shares with the Mobile Node. The SPI 1631 created MUST NOT be a value between zero (0) and 255, which is the 1632 reserved namespace defined in [MOBILEIP]. This AVP MAY be added in 1633 the HAA message by the Home Agent for the AAAH's use in MIP-FA-to-MN- 1634 SPI AVP of the MIP-FA-to-MN-Key AVP. 1636 6.11 MIP-FA-to-HA-SPI AVP 1638 The MIP-FA-to-HA-SPI AVP (AVP Code 318) 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 Home Agent. The SPI 1641 created MUST NOT be a value between zero (0) and 255, which is the 1642 reserved namespace defined in [MOBILEIP]. If FA-HA keys are being 1643 generated, this AVP MUST be added in the HAA message by the Home 1644 Agent for the AAAH's (or AAAF's) use in providing the value of the 1645 MIP-FA-to-HA-SPI member of the grouped MIP-FA-to-HA-Key AVP. 1647 6.12 MIP-Key-Material AVP 1649 The MIP-Key-Material AVP (AVP Code 335) is of type OctetString and 1650 contains the key material sent to the mobile node. The mobile node 1651 follows the procedures in [MIPKEYS] to generate the session key used 1652 to authenticate Mobile IP registration messages. 1654 6.13 MIP-Key-Lifetime AVP 1656 The MIP-Key-Lifetime AVP (AVP Code 367) is of type Unsigned32 and 1657 represents the period of time (in seconds) for which the session key 1658 is valid. The session key MUST NOT be used if the lifetime has 1659 expired; if the key lifetime expires while the session to which it 1660 applies is still active, either the session key MUST be changed or 1661 the or the session MUST be terminated. 1663 7.0 Accounting AVPs 1665 This section will define the Accounting AVPs that are specific to 1666 Mobile IP. 1668 7.1 Accounting-Input-Octets AVP 1670 The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64, 1671 and contains the number of octets in IP packets received from the 1672 user. This AVP MUST be included in all Accounting-Request messages 1673 and MAY be present in the corresponding Accounting-Answer messages as 1674 well. 1676 7.2 Accounting-Output-Octets AVP 1678 The Accounting-Output-Octets AVP (AVP Code 364) is of type 1679 Unsigned64, and contains the number of octets in IP packets sent to 1680 the user. This AVP MUST be included in all Accounting-Request 1681 messages and MAY be present in the corresponding Accounting-Answer 1682 messages as well. 1684 7.3 Acct-Session-Time AVP 1686 The Acct-Time AVP (AVP Code 46) is of type Unsigned32, and indicates 1687 the length of the current session in seconds. This AVP MUST be 1688 included in all Accounting-Request messages and MAY be present in the 1689 corresponding Accounting-Answer messages as well. 1691 7.4 Accounting-Input-Packets AVP 1693 The Accounting-Input-Packets (AVP Code 365) is of type Unsigned64, 1694 and contains the number of IP packets received from the user. This 1695 AVP MUST be included in all Accounting-Request messages and MAY be 1696 present in the corresponding Accounting-Answer messages as well. 1698 7.5 Accounting-Output-Packets AVP 1700 The Accounting-Output-Packets (AVP Code 366) is of type Unsigned64, 1701 and contains the number of IP packets sent to the user. This AVP MUST 1702 be included in all Accounting-Request messages and MAY be present in 1703 the corresponding Accounting-Answer messages as well. 1705 7.6 Event-Timestamp AVP 1707 The Event-Timestamp (AVP Code 55) is of type Time, and MAY be 1708 included in an Accounting-Request message to record the time that 1709 this event occurred on the mobility agent, in seconds since January 1710 1, 1970 00:00 UTC. 1712 8.0 AVP Occurrence Tables 1714 The following tables presents the AVPs defined in this document, and 1715 specifies in which Diameter messages they MAY, or MAY NOT be present. 1716 Note that AVPs that can only be present within a Grouped AVP are not 1717 represented in this table. 1719 The table uses the following symbols: 1720 0 The AVP MUST NOT be present in the message. 1721 0+ Zero or more instances of the AVP MAY be present in the 1722 message. 1723 0-1 Zero or one instance of the AVP MAY be present in the 1724 message. 1725 1 One instance of the AVP MUST be present in the message. 1727 8.1 Mobile IP Command AVP Table 1729 The table in this section is limited to the Command Codes defined in 1730 this specification. 1732 +-----------------------+ 1733 | Command-Code | 1734 |-----+-----+-----+-----+ 1735 Attribute Name | AMR | AMA | HAR | HAA | 1736 ------------------------------|-----+-----+-----+-----+ 1737 Authorization-Lifetime | 0-1 | 0-1 | 1 | 0 | 1738 Auth-Application-Id | 1 | 1 | 1 | 1 | 1739 Auth-Grace-Period | 0-1 | 0-1 | 1 | 0 | 1740 Auth-Session-State | 0-1 | 0-1 | 1 | 0 | 1741 Acct-Multi-Session-Id | 0-1 | 0-1 | 0 | 1 | 1742 Destination-Host | 0-1 | 0 | 0-1 | 0 | 1743 Destination-Realm | 1 | 0 | 1 | 0 | 1744 Error-Message | 0 | 0-1 | 0 | 0-1 | 1745 Error-Reporting-Host | 0 | 0-1 | 0 | 0-1 | 1746 MIP-Candidate-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 | 1747 MIP-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 | 1748 MIP-Originating-Foreign-AAA | 0-1 | 0 | 0-1 | 0 | 1749 MIP-FA-Challenge | 0-1 | 0 | 0 | 0 | 1750 MIP-FA-to-HA-Key | 0 | 0-1 | 0-1 | 0 | 1751 MIP-FA-to-HA-SPI | 0 | 0 | 0 | 0-1 | 1752 MIP-FA-to-MN-Key | 0 | 0-1 | 0 | 0 | 1753 MIP-FA-to-MN-SPI | 0 | 0 | 0 | 0-1 | 1754 MIP-Feature-Vector | 0-1 | 0-1 | 1 | 0 | 1755 MIP-Filter-Rule | 0 | 0+ | 0+ | 0 | 1756 MIP-Foreign-Agent-Host | 0 | 0 | 1 | 0 | 1757 MIP-HA-to-FA-Key | 0 | 0-1 | 0-1 | 0 | 1758 MIP-HA-to-MN-Key | 0 | 0-1 | 0-1 | 0 | 1759 MIP-Home-Agent-Address | 0-1 | 0-1 | 0-1 | 0-1 | 1760 MIP-Key-Lifetime | 0 | 0-1 | 0-1 | 0 | 1761 MIP-MN-AAA-Auth | 1 | 0 | 0 | 0 | 1762 MIP-MN-to-FA-Key | 0 | 0-1 | 0-1 | 0 | 1763 MIP-MN-to-HA-Key | 0 | 0-1 | 0-1 | 0 | 1764 MIP-Mobile-Node-Address | 0-1 | 0-1 | 0-1 | 0-1 | 1765 MIP-Reg-Reply | 0 | 0-1 | 0 | 0-1 | 1766 MIP-Reg-Request | 1 | 0 | 1 | 0 | 1767 Origin-Host | 1 | 1 | 1 | 1 | 1768 Origin-Realm | 1 | 1 | 1 | 1 | 1769 Origin-State-Id | 0-1 | 0-1 | 0-1 | 0-1 | 1770 Proxy-Info | 0+ | 0+ | 0+ | 0+ | 1771 Redirect-Host | 0 | 0+ | 0 | 0+ | 1772 Redirect-Host-Usage | 0 | 0-1 | 0 | 0-1 | 1773 Redirect-Max-Cache-Time | 0 | 0-1 | 0 | 0-1 | 1774 Result-Code | 0 | 1 | 0 | 1 | 1775 Re-Auth-Request-Type | 0 | 0-1 | 0 | 0 | 1776 Route-Record | 0+ | 0 | 0+ | 0 | 1777 Session-Id | 1 | 1 | 1 | 1 | 1778 User-Name | 1 | 0-1 | 1 | 0-1 | 1779 ------------------------------|-----+-----+-----+-----| 1781 8.2 Accounting AVP Table 1783 The table in this section is used to represent which AVPs defined in 1784 this document are to be present in the Accounting messages, defined 1785 in [DIAMBASE]. 1787 +-------------+ 1788 | Command-Code| 1789 |------+------+ 1790 Attribute Name | ACR | ACA | 1791 -------------------------------------|------+------+ 1792 Accounting-Input-Octets | 1 | 0-1 | 1793 Accounting-Input-Packets | 1 | 0-1 | 1794 Accounting-Output-Octets | 1 | 0-1 | 1795 Accounting-Output-Packets | 1 | 0-1 | 1796 Accounting-Multi-Session-Id | 1 | 0-1 | 1797 Acct-Session-Time | 1 | 0-1 | 1798 MIP-Feature-Vector | 1 | 0-1 | 1799 MIP-Home-Agent-Address | 1 | 0-1 | 1800 MIP-Mobile-Node-Address | 1 | 0-1 | 1801 Event-Timestamp | 0-1 | 0 | 1802 -------------------------------------|------+------+ 1804 9.0 IANA Considerations 1806 This section contains the namespaces that have either been created in 1807 this specification, or the values assigned to existing namespaces 1808 managed by IANA. 1810 9.1 Command Codes 1812 This specification assigns the values 260 and 262 from the Command 1813 Code namespace defined in [DIAMBASE]. See section 2.0 for the 1814 assignment of the namespace in this specification. 1816 9.2 AVP Codes 1818 This specification assigns the values 318-348 and 363-367 from the 1819 AVP Code namespace defined in [DIAMBASE]. See sections 4.0 and 6.0 1820 for the assignment of the namespace in this specification. 1822 9.3 Result-Code AVP Values 1824 This specification assigns the values 4005-4007, and 5024-5025 from 1825 the Result-Code AVP (AVP Code 268) value namespace defined in 1826 [DIAMBASE]. See section 3.0 for the assignment of the namespace in 1827 this specification. 1829 9.4 MIP-Feature-Vector AVP Values 1831 There are 32 bits in the MIP-Feature-Vector AVP (AVP Code 337) that 1832 are available for assignment. This document assigns bits 1-9, as 1833 listed in section 4.5. The remaining bits should only be assigned via 1834 Standards Action [IANA]. 1836 9.5 MIP-Algorithm-Type AVP Values 1838 As defined in Section 6.8, the MIP-Algorithm-Type AVP (AVP Code 345) 1839 defines the values 1-3. All remaining values are available for 1840 assignment via Designated Expert [IANA]. 1842 9.6 MIP-Replay-Mode AVP Values 1844 As defined in Section 6.9, the MIP-Replay-Mode AVP (AVP Code 346) 1845 defines the values 1-3. All remaining values, except zero, are 1846 available for assignment via Designated Expert [IANA]. 1848 9.7 Application Identifier 1850 This specification assigns the value four (4) to the Application 1851 Identifier namespace defined in [DIAMBASE]. See section 1.7 for more 1852 information. 1854 10.0 Security Considerations 1856 This specification describes the Diameter Application necessary to 1857 authenticate and authorize a Mobile IP Mobile Node. The 1858 authentication algorithm used is dependent upon the transforms 1859 available by the Mobile IP protocol, and [MIPCHAL]. This 1860 specification also defines a method by which the home Diameter server 1861 can create and distribute session keys to be used to authenticate 1862 Mobile IP registration messages. The keys SHOULD be be protected 1863 using the methods defined in [CMS]. 1865 11.0 References 1867 11.1 Normative 1869 [DIAMBASE] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens, 1870 "Diameter Base Protocol", draft-ietf-aaa-diameter-11.txt, 1871 IETF work in progress, November 2001. 1873 [IANA] Narten, Alvestrand,"Guidelines for Writing an IANA Con� 1874 siderations Section in RFCs", BCP 26, RFC 2434, October 1875 1998 1877 [MOBILEIP] C. Perkins, Editor. IP Mobility Support. RFC 3220, Jan� 1878 uary 2002. 1880 [MIPCHAL] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response 1881 Extensions". RFC 3012. November 2000. 1883 [NAI] B. Aboba, M. Beadles "The Network Access Identifier." RFC 1884 2486. January 1999. 1886 [HMAC] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed- 1887 Hashing for Message Authentication. RFC 2104, February 1888 1997. 1890 [MIPKEYS] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile 1891 IP", draft-ietf-mobileip-aaa-key-09.txt, IETF work in 1892 progress, July 2001. 1894 [AAANAI] F. Johansson, T.Johansson, "AAA NAI for Mobile IPv4 1895 Extension", draft-mobileip-aaa-nai-00.txt, IETF work in 1896 progress, March 2002. 1898 11.2 Informative 1900 [MIPREQ] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentica� 1901 tion, Authorization, and Accounting Requirements". RFC 1902 2977. October 2000. 1904 [CDMA2000] T. Hiller and al, "CDMA2000 Wireless Data Requirements 1905 for AAA", RFC 3141, June 2001. 1907 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 1908 Requirement Levels", BCP 14, RFC 2119, March 1997. 1910 [EVALROAM] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Pro� 1911 tocols", RFC 2477, January 1999. 1913 [MIPNAI] P. Calhoun, C. Perkins, "Mobile IP Network Address Iden� 1914 tifier Extension", RFC 2794, March 2000. 1916 [CMS] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security 1917 Application", draft-ietf-aaa-diameter-cms-sec-05.txt, 1918 IETF work in progress, April 2002. 1920 [RANDOM] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Random� 1921 ness Recommendations for Security. Request for Comments 1922 (Informational) 1750, Internet Engineering Task Force, 1923 December 1994. 1925 12.0 Acknowledgements 1927 The authors would like to thank Nenad Trifunovic, Haseeb Akhtar and 1928 Pankaj Patel for their participation in the pre-IETF Document Reading 1929 Party, to Erik Guttman for his very useful proposed text, and to 1930 Fredrik Johansson, Martin Julien and Bob Kopacz for their very useful 1931 contributed text. 1933 The authors would also like to thank the participants of 3GPP2's TSG- 1934 P working group for their valuable feedback and also the following 1935 people for their contribution in the development of the protocol: 1937 Kevin Purser, Thomas Panagiotis, Mark Eklund, Paul Funk, Michael 1938 Chen, Henry Haverinen, Johan Johansson 1940 Finally, Pat Calhoun would like to thank Sun Microsystems since most 1941 of the effort put into this document was done while he was in their 1942 employ. 1944 13.0 Authors' Addresses 1946 Questions about this memo can be directed to: 1948 Pat R. Calhoun 1949 Black Storm Networks 1950 250 Cambridge Avenue, Suite 200 1951 Palo Alto, California, 94306 1952 USA 1954 Phone: +1 650-617-2932 1955 Fax: +1 650-786-6445 1956 E-mail: pcalhoun@bstormnetworks.com 1957 Tony Johansson 1958 Ericsson Inc 1959 2100 Shattuck Avenue 1960 Berkeley, California 94704 1961 USA 1963 Phone: +1 510-541-8783 1964 Fax: +1 510-666-3900 1965 E-Mail: tony.johansson@ericsson.com 1967 Charles E. Perkins 1968 Nokia Research Center 1969 313 Fairchild Drive 1970 Mountain View, California 94043 1971 USA 1973 Phone: +1 650-625-2986 1974 Fax: +1 650-625-2502 1975 E-Mail: charliep@iprg.nokia.com 1977 Copyright (C) The Internet Society (2001). All Rights Reserved. 1979 This document and translations of it may be copied and furnished to 1980 others, and derivative works that comment on or otherwise explain it 1981 or assist in its implementation may be prepared, copied, published 1982 and distributed, in whole or in part, without restriction of any 1983 kind, provided that the above copyright notice and this paragraph are 1984 included on all such copies and derivative works. However, this docu� 1985 ment itself may not be modified in any way, such as by removing the 1986 copyright notice or references to the Internet Society or other 1987 Internet organizations, except as needed for the purpose of develop� 1988 ing Internet standards in which case the procedures for copyrights 1989 defined in the Internet Standards process must be followed, or as 1990 required to translate it into languages other than English. The lim� 1991 ited permissions granted above are perpetual and will not be revoked 1992 by the Internet Society or its successors or assigns. This document 1993 and the information contained herein is provided on an "AS IS" basis 1994 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS� 1995 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 1996 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1997 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1998 FITNESS FOR A PARTICULAR PURPOSE. 2000 15.0 Expiration Date 2002 This memo is filed as and 2003 expires in October 2002.