idnits 2.17.1 draft-ietf-aaa-diameter-mobileip-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 33 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 34 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 16 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. == 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 table 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 (March 2001) is 8443 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 1386, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1412, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1422, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-01 -- No information found for draft-ietf-aaa- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 2977 (ref. '3') ** Obsolete normative reference: RFC 2002 (ref. '4') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 3012 (ref. '5') (Obsoleted by RFC 4721) ** Obsolete normative reference: RFC 2486 (ref. '6') (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2477 (ref. '7') == Outdated reference: A later version (-07) exists of draft-calhoun-diameter-strong-crypto-06 -- Possible downref: Normative reference to a draft: ref. '9' ** Obsolete normative reference: RFC 2406 (ref. '10') (Obsoleted by RFC 4303, RFC 4305) -- Possible downref: Normative reference to a draft: ref. '12' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '13') == Outdated reference: A later version (-17) exists of draft-ietf-aaa-diameter-nasreq-01 -- Unexpected draft version: The latest known version of draft-calhoun-mobileip-aaa-key is -00, but you're referring to -03. (However, the state information for draft-ietf-aaa- is not up-to-date. The last update was unsuccessful) -- Possible downref: Normative reference to a draft: ref. '15' == Outdated reference: A later version (-02) exists of draft-hiller-cdma2000-aaa-01 ** Downref: Normative reference to an Informational draft: draft-hiller-cdma2000-aaa (ref. '16') == Outdated reference: A later version (-08) exists of draft-calhoun-diameter-res-mgmt-06 -- Possible downref: Normative reference to a draft: ref. '17' ** Obsolete normative reference: RFC 2279 (ref. '18') (Obsoleted by RFC 3629) Summary: 15 errors (**), 0 flaws (~~), 13 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AAA Working Group Pat R. Calhoun 3 Internet-Draft Sun Laboratories, Inc. 4 Category: Standards Track Charles E. Perkins 5 Nokia Research Center 6 March 2001 8 Diameter Mobile IP Extensions 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at: 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at: 29 http://www.ietf.org/shadow.html. 31 This document is an individual contribution for consideration by the 32 AAA Working Group of the Internet Engineering Task Force. Comments 33 should be submitted to the mobileip@nortelnetworks.com mailing list. 35 Distribution of this memo is unlimited. 37 Copyright (C) The Internet Society 2001. All Rights Reserved. 39 Abstract 41 This document specifies an extension to the Diameter base protocol 42 that allows a Diameter server to authenticate, authorize and collect 43 accounting information for services rendered to a mobile node. 44 Combined with the Inter-Domain capability of the base protocol, this 45 extension allows mobile nodes to receive service from foreign service 46 providers. The Diameter Accounting extension will be used by the 47 Foreign and Home agents to transfer usage information to the Diameter 48 servers. 50 Table of Contents 52 1.0 Introduction 53 1.1 Requirements language 54 1.2 Inter-Domain Mobile IP 55 1.3 Allocation of Home Agent in Foreign Network 56 1.4 Diameter Session Termination 57 2.0 Command-Code Values 58 2.1 AA-Mobile-Node-Request (AMR) Command 59 2.2 AA-Mobile-Node-Answer (AMA) Command 60 2.3 Home-Agent-MIP-Request (HAR) Command 61 2.4 Home-Agent-MIP-Answer (HAA) Command 62 2.5 Home-Agent-Allocated-Ind (HAI) Command 63 3.0 Result-Code AVP Values 64 3.1 Hop-by-Hop Failures 65 4.0 Diameter AVPs 66 4.1 MIP-Reg-Request AVP 67 4.2 MIP-Reg-Reply AVP 68 4.3 MIP-Mobile-Node-Address AVP 69 4.4 MIP-Home-Agent-Address AVP 70 4.5 MIP-Previous-FA-NAI AVP 71 4.6 MIP-Previous-FA-Addr AVP 72 4.7 MIP-Feature-Vector AVP 73 4.8 MIP-MN-AAA-Auth AVP 74 4.8.1 MIP-MN-AAA-SPI AVP 75 4.8.2 MIP-Auth-Input-Data-Length AVP 76 4.8.3 MIP-Authenticator-Length AVP 77 4.8.4 MIP-Authenticator-Offset AVP 78 5.0 Key Distribution Center 79 5.1 Distributing the Mobile-Home Registration Key 80 5.2 Distributing the Mobile-Foreign Registration Key 81 5.3 Distributing the Foreign-Home Registration Key 82 5.4 Key Distribution Example 83 6.0 Key Distribution Center (KDC) AVPs 84 6.1 Mobile Node Session Keys 85 6.1.1 MIP-MN-to-FA-Key AVP 86 6.1.2 MIP-MN-to-HA-Key AVP 87 6.2 Mobility Agent Session Keys 88 6.2.1 MIP-FA-to-MN-Key AVP 89 6.2.2 MIP-FA-to-HA-Key AVP 90 6.2.3 MIP-HA-to-FA-Key AVP 91 6.2.4 MIP-HA-to-MN-Key AVP 92 6.2.5 MIP-Peer-SPI AVP 93 6.2.6 MIP-Session-Key AVP 94 6.3 FA-MN-Preferred-SPI AVP 95 6.4 FA-HA-Preferred-SPI AVP 96 7.0 Accounting Considerations 97 8.0 Interactions with Resource Management 98 9.0 AVP Table 99 10.0 Acknowledgements 100 11.0 IANA Considerations 101 12.0 Security Considerations 102 13.0 References 103 14.0 Authors' Addresses 104 15.0 Full Copyright Statement 106 1.0 Introduction 108 Mobile IP, as defined in [4], defines a method that allows a Mobile 109 Node to change its point of attachment to the Internet with minimal 110 service disruption. Mobile IP does not provide any specific support 111 for mobility across disparate administrative domains, and therefore 112 does not specify how usage can be accounted for, which has limited 113 the applicability of Mobile IP in a IPv4 commercial deployment. The 114 Mobile IP protocol [4] requires that mobile nodes have static home 115 agent and home addresses, which is not desirable in a commercial 116 network. Recent specification [8] allows a mobile node to use its 117 NAI instead of its home address, which better accommodates current 118 administrative practice. 120 This document specifies Extension 4 to the Diameter base protocol [1] 121 that allows a Diameter server to authenticate, authorize and collect 122 accounting information for services rendered to a mobile node. 123 Diameter nodes conforming to this specification MUST include an 124 Extension-Id AVP with a value of four in the Device-Reboot-Ind 125 Command [1]. Combined with the Inter-Domain capability of the base 126 protocol, this extension allows mobile nodes to receive service from 127 foreign service providers. The Diameter Accounting extension [12] 128 will be used by the Foreign and Home agents to transfer usage 129 information to the Diameter servers. 131 The Mobile IP protocol [4] specifies a security model that requires 132 that mobile nodes and home agents share a pre-existing security 133 association, which leads to scaling and configuration issues. This 134 specification defines Diameter functions that allow the AAA server to 135 act as a Key Distribution Center (KDC), whereby dynamic registration 136 keys are created and distributed to the mobility entities for the 137 purposes of securing Mobile IP Registration messages. 139 As with the Diameter base protocol, AAA servers implementing the 140 Mobile IP extension can process users' identities supplied in a 141 Network Access Identifier (NAI) format [6], which is used for 142 Diameter message routing purposes. Mobile nodes include their NAI in 143 Registration messages, as defined in [8]. The use of the NAI is 144 consistent with the roaming model defined by the ROAMOPS Working 145 Group [7]. 147 The Diameter Mobile-IP Extension meets the requirements specified in 148 [3, 16]. Later subsections in this introductory section provide some 149 examples and message flows of the Mobile IP and Diameter messages 150 that occur when a Mobile Node requests service in a foreign network. 151 In this document, the role of the "attendant" [3] is performed by the 152 foreign agent for the Mobile-IP Extension, and these terms will be 153 used interchangeably. 155 1.1 Requirements language 157 In this document, the key words "MAY", "MUST", "MUST NOT", 158 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 159 interpreted as described in [11]. 161 1.2 Inter-Domain Mobile IP 163 When a Mobile Node node requests service by issuing a Registration 164 Request to the foreign agent, the foreign agent creates the AA- 165 Mobile-Node-Request (AMR) message, which includes the AVPs defined in 166 section 2.1. The Home Address, Home Agent, Mobile Node NAI and other 167 important fields are extracted from the registration messages for 168 possible inclusion as Diameter AVPs. The AMR message is then 169 forwarded to the local Diameter server, known as the AAA-Foreign, or 170 AAAF. 172 Visited Domain Home Domain 173 +--------+ +--------+ 174 |abc.com | AMR/AMA |xyz.com | 175 | AAAF |<------------------->| AAAH | 176 +->| server | server-server | server | 177 | +--------+ communication +--------+ 178 | ^ ^ 179 | AMR/AMA | client-server | HAR/HAA 180 | | communication | 181 v v v 182 +---------+ +---------+ +---------+ 183 | Foreign | | Foreign | | Home | 184 | Agent | | Agent | | Agent | 185 +---------+ +---------+ +---------+ 186 ^ 187 | Mobile IP 188 | 189 v 190 +--------+ 191 | Mobile | 192 | Node | mn@xyz.com 193 +--------+ 194 Figure 1: Inter-Domain Mobility 196 Upon receiving the AMR, the AAAF follows the procedures outlined in 197 [1] to determine whether the AMR should be processed locally, or if 198 it should be forwarded to another Diameter Server, known as the AAA- 199 Home, or AAAH. Figure 1 shows an example in which a mobile node 200 (mn@xyz.com) requests service from a foreign provider (abc.com). The 201 request received by the AAAF is forwarded to xyz.com's AAAH server. 203 Figure 2 shows the message flows involved when the attendant (foreign 204 agent) invokes the AAA infrastructure to request that a mobile node 205 be authenticated and authorized. Note that it is not required that 206 the foreign agent invoke AAA services every time a Registration 207 Request is received from the mobile, but rather only when the prior 208 authorization from the AAAH expires. The expiration time of the 209 authorization (and registration keys, if allocated by the AAA server) 210 is communicated through the Authorization-Lifetime AVP in the AA- 211 Mobile-Node-Answer (AMA, see section 2.2) from the AAAH. 213 Mobile Node Foreign Agent AAAF AAAH Home Agent 214 ----------- ------------- ------------ ---------- ---------- 215 Advertisement & 216 <--------- Challenge 217 Reg-Req&MN-AAA ----> 218 AMR-------------> 219 AMR------------> 220 HAR-----------> 221 <----------HAA 222 <-----------AMA 223 <------------AMA 224 <-------Reg-Reply 226 Figure 2: Mobile IP/Diameter Message Exchange 228 The foreign agent (as shown in Figure 2) MAY provide a challenge, 229 which gives it direct control over the replay protection in the 230 Mobile IP registration process, as described in [5]. The mobile node 231 includes the Challenge and MN-AAA authentication extension to enable 232 authorization by AAAH. If the authentication data supplied in the 233 MN-AAA extension is invalid, AAAH returns the response (AMA) with the 234 Result-Code AVP set to DIAMETER_ERROR_AUTH_FAILURE (see section 3.0). 236 If the Mobile Node was successfully authenticated, the AAAH checks 237 for the MIP-Home-Agent-Address AVP. If one was specified, the AAAH 238 checks that the address is that of a known Home Agent, and one that 239 the Mobile Node is allowed to request. If no Home Agent was 240 specified, and if the MIP-Feature-Vector has the Home-Agent-Requested 241 flag set, and if allowed by policy in the home domain, the AAAH 242 SHOULD allocate a home agent on behalf of the Mobile Node. This can 243 be done in a variety of ways, including using a load balancing 244 algorithm in order to keep the load on all home agents equal. The 245 actual algorithm used and the method of discovering the home agents 246 is outside the scope of this specification. 248 If AAAH does not know the address of the home agent (perhaps because 249 it will be allocated by AAAF within the visited domain as described 250 in section 1.3), then AAAH sends an AMA message back to AAAF which 251 does not contain a MIP-Reg-Reply AVP. 253 Otherwise, if the home agent address is known, the AAAH then sends a 254 Home-Agent-MIP-Request (HAR), which contains the Mobile IP 255 Registration Request message data encapsulated in the MIP-Reg-Request 256 AVP, to the assigned or requested Home Agent. The AAAH MAY allocate a 257 home address for the mobile node, and include it in a MIP-Mobile- 258 Node-Address AVP within the HAR, or else leave this allocation 259 responsibility for the Home Agent. 261 Upon receipt of the HAR, the Home Agent first processes the Diameter 262 message. If the HAR is invalid, a HAA is returned with the Result- 263 Code AVP set to DIAMETER_ERROR_BAD_HAR (see section 3.0). Otherwise, 264 the Home Agent processes the MIP-Reg-Req AVP and creates the 265 Registration Reply, encapsulating it within the MIP-Reg-Reply AVP. 266 If a home address is needed, the Home Agent MUST assign one and 267 include the address in both the Registration Reply and within the 268 MIP-Mobile-Node-Address AVP. The Diameter response is then forwarded 269 to the AAAH. 271 Upon receipt of the HAA, the AAAH sets the Command-Code field to AA- 272 Mobile-Node-Answer (AMA) and forwards the message to the AAAF. The 273 AAAH includes the MIP-Home-Agent-Address and MIP-Mobile-Node-Address 274 AVPs in the AMA message, enabling appropriate firewall controls for 275 the penetration of tunneled traffic between the Home Agent and the 276 Mobile Node. 278 The AAAF is responsible for ensuring that the AMA message is properly 279 forwarded to the correct foreign agent. 281 1.3 Allocation of Home Agent in Foreign Network 283 The Diameter Mobile IP extension allows a Home Agent to be allocated 284 in a foreign network, as required in [3, 16]. When a foreign agent 285 detects that the mobile node has a home agent address equal to 286 0.0.0.0 or 255.255.255.255 in the Registration Request message, it 287 MUST add a MIP-Feature-Vector AVP with the Home-Agent-Requested flag 288 set to one. If the home address address is equal to 255.255.255.255, 289 then the foreign agent also MUST set the Home-Address-Allocatable- 290 Only-in-Home-Domain flag equal to one. 292 When the AAAF receives a AMR message with the Home-Agent-Requested 293 flag set to one, and the Home-Address-Allocatable-Only-in-Home-Domain 294 flag equal to zero, AAAF MAY set the Foreign-Home-Agent-Available 295 flag in the MIP-Feature-Vector AVP to inform the AAAH that it is 296 willing and able to assign a Home Agent for the Mobile Node. 298 In the event that the mobile node requests a home agent in the 299 foreign network, and the AAAF authorizes its use, the AAAF MUST set 300 the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. 301 This could happen when the AAA request is sent to "extend" a mobile 302 node's current session. 304 When the AAAH receives a AMR message, it first checks the 305 authentication data supplied by the mobile node, according to the 306 MIP-Reg-Req AVP and MIP-MN-AAA-Auth AVP, and determines whether to 307 authorize the mobile node. If the AMR indicates that the AAAF has 308 offered to allocate a home agent for the mobile node, then the AAAH 309 must decide whether its local policy would allow the user to have a 310 Home Agent in the foreign network. If so, and after checking 311 authorization from the data in the AMR message, the AAAH sends the 312 AMA message to the AAAF that does not contain the MIP-Home-Agent- 313 Address. 315 Visited Domain Home Domain 316 +--------+ +--------+ 317 | | AMR/AMA | | 318 | AAAF |<------------------>| AAAH | 319 +--->| server | server-server | server | 320 | +--------+ communication +--------+ 321 | ^ 322 | | 323 HAR/HAA | AMR/AMA | client-server 324 v v communication 325 +---------+ +---------+ 326 | Home | | Foreign | 327 | Agent | | Agent | 328 +---------+ +---------+ 329 ^ 330 +--------+ | 331 | Mobile |<----------+ 332 | Node | Mobile IP 333 +--------+ 334 Figure 3: Home Agent allocated in Visited Domain 336 Upon receipt of a HAA from the Home Agent in the Visited Domain, with 337 the Result-Code AVP indicating success, the AAAF MUST issue a HAI 338 message to the AAAH. The HAI message MUST include the MIP-Home- 339 Agent-Address and the MIP-Mobile-Node-Address AVPs. 341 Mobile Node Foreign Agent Home Agent AAAF AAAH 342 ----------- ------------- ------------- ---------- ---------- 344 <----Challenge---- 345 Reg-Req (Response)-> 346 ------------AMR-------------> 347 -----AMR----> 348 <----AMA----- 349 <-----HAR------ 350 ------HAA------> 351 <-------------AMA------------AMA 352 ---HAI------> 353 <---Reg-Reply---- 354 Figure 4: Mobile IP/Diameter Message Exchange 356 If the Mobile Node moves to another Foreign Network, it MAY either 357 request to keep the same Home Agent within the old foreign network, 358 or request to get a new one in the new foreign network. If the AAAH 359 is willing to provide the requested service, the mobile node will 360 have to interact with two AAAFs. 362 Figure 5 shows the message flows for a Mobile Node requesting to keep 363 the Home Agent assigned in Foreign network 1 when it moves to foreign 364 network 2. Upon reception of the AMR in Foreign network 2, the AAAF 365 follows the procedures described earlier and forwards AMR to the 366 Mobile Node's home network, i.e. its AAAH. If the Mobile Node was 367 successfully authenticated the AAAH checks for the MIP-Home-Agent- 368 Address and the MIP-Previous-FA-NAI AVPs. If a Home Agent was 369 specified, and it belongs to a different domain than the Foreign 370 Agent in the MIP-Previous-FA-NAI AVP, the AAAH MUST verify whether it 371 will permit this type of the service to the Mobile Node. 373 +---------------+ +---------------+ +-------------+ 374 |Foreign net 2 | |Foreign net 1 | |Home network | 375 | | | | | | 376 Mobile Node | FA AAAF | | HA AAAF | | AAAH | 377 ----------- | ---- ---- | | ---- ------ | | ------ | 378 +---------------+ +---------------+ +-------------+ 380 <----Challenge---- 381 Reg-Req (Response)-> 382 ---AMR---> 383 ----------------AMR---------------> 384 <-----HAR----- 385 <--HAR--- 386 --HAR--> 387 ------HAA----> 388 <--------------AMA---------------- 389 <--AMA---- 390 <-Reg-Reply-- 391 Figure 5: Request to access Home Agent from new Foreign Network 393 If the Mobile Node is allowed to keep the Home Agent the AAAH then 394 sends a HAR, which contains the Mobile IP Registration Request 395 message data encapsulated in the MIP-Reg-Request AVP and the MIP- 396 Home-Agent-Address AVP with Home Agent address, the optional KDC 397 session keys to the AAAF in foreign network 1. Upon reception the 398 AAAF in foreign network 1 will forward the HAR to the Home Agent if 399 its local policy allows such service. If the AAAF does not permit 400 such service, it MUST return a DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. 402 When the AAAF receives a successful HAA, the AAAF will forward the 403 HAA back to the AAAH. The HAA MUST include the MIP-Home-Agent-Address 404 and the MIP-Mobile-Node-Address AVPs. The AAAH will then send back an 405 AMA to the AAAF in foreign network 2. 407 If the old Foreign Network does not permit the use of its Home Agent 408 when the Mobile Node moves to a new foreign network, the Mobile Node 409 MAY allocate a new Home Agent in its current network, as described 410 above. However, when the AAAH receives such a request, it MUST send a 411 Diameter Session-Termination-Indication message to the old AAAF, 412 which will enable the old foreign network to release any resources, 413 and will cause any necessary accounting messages. 415 [ed: Charlie would prefer that the AMA be sent directly from foreign 416 net 1 to foreign net 2. This would optimize the signaling, and would 417 reduce latency involved in the handoff. More work needed here] 419 1.4 Diameter Session Termination 421 A Foreign and Home Agent following this specification MAY expect 422 their respective Diameter servers to maintain session state 423 information for each mobile node in their networks. In order for the 424 Diameter Server to release any resources allocated to a specific 425 mobile node, the mobility agents MUST send a Session-Termination- 426 Request (STR) [1] to their respective Diameter servers. 428 The Home Diameter server SHOULD only deallocate all resources after 429 the STR is received from the Home Agent. This ensures that a Mobile 430 Node that moves from one Foreign Agent to another (hand-off) does not 431 cause the Home Diameter Server to free all resources for the Mobile 432 Node. The Diameter Server is free to initiate the session termination 433 at any time by issuing the Session-Termination-Ind (STI) [1]. 435 2.0 Command-Code Values 437 This section defines Command-Code [1] values that MUST be supported 438 by all Diameter implementations conforming to this specification. 439 The following Command Codes are defined in this specification: 441 Command-Name Abbreviation Code Section 442 ----------------------------------------------------------- 443 AA-Mobile-Node-Answer AMA 261 2.2 444 AA-Mobile-Node-Request AMR 260 2.1 445 Home-Agent-Allocated-Ind HAI 279 2.5 446 Home-Agent-MIP-Answer HAA 263 2.4 447 Home-Agent-MIP-Request HAR 262 2.3 449 2.1 AA-Mobile-Node-Request (AMR) Command 451 The AA-Mobile-Node-Request (AMR), indicated by the Command-Code field 452 set to 260, is sent by an attendant, acting as a Diameter client, to 453 a server in order to request the authentication and authorization of 454 a Mobile Node. The Foreign Agent uses information found in the 455 Registration Request to construct the following AVPs that are to be 456 included as part of the AMR: 458 home address (MIP-Mobile-Node-Address AVP), 459 home agent address (MIP-Home-Agent-Address AVP), 460 mobile node NAI (User-Name AVP [1]). 462 If the mobile node's home address is zero, the foreign agent MUST NOT 463 include a MIP-Mobile-Node-Address AVP in the AMR. In this case, the 464 AAAF MAY set the Foreign-Home-Agent-Available flag in the MIP- 465 Feature-Vector AVP in the AMR message to indicate that it is willing 466 to assign a Home Agent in the visited domain. 468 If the MIP-Previous-FA-NAI AVP is found in the request, the Diameter 469 client requests that the server return the registration key that was 470 assigned to the previous Foreign Agent for use with the Mobile Node 471 and Home Agent. The registration key is identified through the use of 472 the MIP-Mobile-Node-Address AVP. 474 Message Format 476 ::= < Diameter Header: 260 > 477 { Session-ID } 478 { Extension-Id } 479 { User-Name } 480 { Destination-Realm } 481 { Origin-FQDN } 482 { Origin-Realm } 483 { Authorization-Lifetime } 484 { MIP-Reg-Request } 485 { MIP-MN-AAA-Auth } 486 [ MIP-Mobile-Node-Address ] 487 [ MIP-Home-Agent-Address ] 488 [ MIP-Feature-Vector ] 489 [ MIP-FA-MN-Preferred-SPI ] 490 [ MIP-FA-HA-Preferred-SPI ] 491 [ MIP-Previous-FA-NAI ] 492 [ MIP-Previous-FA-Addr ] 493 * [ AVP ] 494 * [ Proxy-State ] 495 * [ Route-Record ] 496 0*1< Integrity-Check-Value > 498 2.2 AA-Mobile-Node-Answer (AMA) Command 500 The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code field 501 set to 261, is sent by the AAAH in response to the AA-Mobile-Node- 502 Request message. The Result-Code AVP MAY contain one of the values 503 defined in section 3.0, in addition to the values defined in [1]. If 504 the home agent is situated in the home domain, a successful response 505 MUST include the MIP-Reg-Reply AVP. 507 The MIP-Home-Agent-Address AVP contains the Home Agent assigned to 508 the Mobile Node, while the MIP-Mobile-Node-Address AVP contains the 509 home address that was assigned. 511 The AMA message MUST contain the MIP-FA-to-HA-Key, MIP-FA-to-MN-Key 512 and MIP-Reg-Reply AVPs if they were received by AAAH in the HAA 513 message. 515 Message Format 517 ::= < Diameter Header: 261 > 518 < Session-Id > 519 { Extension-Id } 520 { Session-Timeout } 521 { Authorization-Lifetime } 522 { Result-Code } 523 { Destination-Realm } 524 [ Error-Reporting-FQDN ] 525 [ Origin-FQDN ] 526 [ MIP-Reg-Reply ] 527 [ MIP-MN-to-HA-Key ] 528 [ MIP-FA-to-MN-Key ] 529 [ MIP-FA-to-HA-Key ] 530 [ MIP-Home-Agent-Address ] 531 [ MIP-Mobile-Node-Address ] 532 * [ AVP ] 533 * [ Proxy-State ] 534 * [ Route-Record ] 535 0*1< Integrity-Check-Value > 537 2.3 Home-Agent-MIP-Request (HAR) Command 539 The Home-Agent-MIP-Request (HAR), indicated by the Command-Code field 540 set to 262, is sent by the AAA to the Home Agent. If the Home Agent 541 is to be assigned in a foreign network, the HAR is issued by AAAF. 542 If the HAR message does not include a MIP-Mobile-Node-Address AVP, 543 and the Registration Request has 0.0.0.0 for the home address, and 544 the HAR is successfully processed, the Home Agent MUST allocate one 545 such address to the mobile node. If the home agent's local AAA server 546 allocates the mobile node's home address, it MUST include the 547 assigned address in an MIP-Mobile-Node-Address AVP. 549 If a AAAF receives a HAR that does not include the MIP-Reg-Reply AVP, 550 then a Home Agent MUST be assigned in the foreign network. 552 When registration keys are requested for use by the mobile node (see 553 section 5.0), the AAAH MUST create them and include them in the HAR 554 message. When a Foreign-Home registration key is requested, it will 555 be created and distributed by the AAA server in the same domain as 556 the home agent. 558 Message Format 560 ::= < Diameter Header: 262 > 561 < Session-Id > 562 { Extension-Id } 563 { Session-Timeout } 564 { Authorization-Lifetime } 565 { MIP-Reg-Request } 566 { Origin-FQDN } 567 { Origin-Realm } 568 { User-Name } 569 { Destination-Realm } 570 [ MIP-MN-to-HA-Key ] 571 [ MIP-MN-to-FA-Key ] 572 [ MIP-HA-to-MN-Key ] 573 [ MIP-HA-to-FA-Key ] 574 [ MIP-FA-to-MN-Key ] 575 [ MIP-FA-to-HA-Key ] 576 [ MIP-Mobile-Node-Address ] 577 * [ AVP ] 578 * [ Proxy-State ] 579 * [ Route-Record ] 580 0*1< Integrity-Check-Value > 582 2.4 Home-Agent-MIP-Answer (HAA) Command 584 The Home-Agent-MIP-Answer (HAA), indicated by the Command-Code field 585 set to 263, is sent by the Home Agent to its local AAA server in 586 response to a Home-Agent-MIP-Request. If the home agent allocated a 587 home address for the Mobile Node, the address MUST be included in the 588 MIP-Mobile-Node-Address AVP. The Result-Code AVP MAY contain one of 589 the values defined in section 3.0 instead of the values defined in 590 [1]. 592 Message Format 594 ::= < Diameter Header: 263 > 595 < Session-Id > 596 { Extension-Id } 597 { Session-Timeout } 598 { Authorization-Lifetime } 599 { Result-Code } 600 { Origin-FQDN } 601 { Origin-Realm } 602 { Destination-Realm } 603 [ Error-Reporting-FQDN ] 604 [ MIP-Reg-Reply ] 605 [ MIP-Home-Agent-Address ] 606 [ MIP-Mobile-Node-Address ] 607 [ MIP-FA-to-MN-Key ] 608 [ MIP-FA-to-HA-Key ] 609 * [ AVP ] 610 * [ Proxy-State ] 611 * [ Route-Record ] 612 0*1< Integrity-Check-Value > 614 2.5 Home-Agent-Allocated-Ind (HAI) Command 616 The Home-Agent-Allocated-Ind (HAI), indicated by the Command-Code 617 field set to 279, is sent by the AAAF to the AAAH upon receipt of a 618 successful HAA when the Home Agent was assigned in the visited 619 network. The HAI MUST include the MIP-Home-Agent-Address and MIP- 620 Mobile-Node-Address AVPs. 622 Message Format 624 ::= < Diameter Header: 279 > 625 < Session-Id > 626 { Extension-Id } 627 { Origin-FQDN } 628 { Origin-Realm } 629 { Session-Timeout } 630 { Authorization-Lifetime } 631 { Destination-Realm } 632 { Destination-FQDN } 633 [ MIP-Home-Agent-Address ] 634 [ MIP-Mobile-Node-Address ] 635 * [ AVP ] 636 * [ Proxy-State ] 637 * [ Route-Record ] 638 0*1< Integrity-Check-Value > 640 3.0 Result-Code AVP Values 642 This section defines new Result-Code [1] values that MUST be 643 supported by all Diameter implementations that conform to this 644 specification. 646 3.1 Hop-by-Hop Failures 648 Proxies receiving messages with the Result-Code AVP set to an error 649 within the Hop-by-Hop failure category SHOULD attempt to take some 650 local action to correct the error. If no local action can be taken to 651 correct the problem, the error MUST be forwarded towards the 652 originator of the message. 654 DIAMETER_ERROR_BAD_KEY 6009 655 This error code is used by the Home Agent to indicate to the 656 local Diameter server that the key generated is invalid. 658 DIAMETER_ERROR_BAD_HOME_ADDRESS 6010 659 This error code is used by the Home Agent to indicate that the 660 Home Address chosen by the Mobile Node or assigned by the local 661 Diameter server is unavailable. 663 DIAMETER_ERROR_AUTH_FAILURE 6011 664 This error code is used by AAAH to inform AAAF that the 665 authentication data in the MN-AAA authentication extension is 666 invalid. 668 DIAMETER_ERROR_MIP_REPLY_FAILURE 6012 669 This error code is used by the Home Agent when processing of 670 the Registration Request has failed. 672 DIAMETER_ERROR_BAD_HAR-day 6013 673 This error code is used by HA to inform the AAA server that the 674 Home-Agent-Request (HAR) message could not be processed 675 correctly. 677 DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE 6014 678 This error is used by the AAAF to inform the AAAH that 679 allocation of a Home Agent in the Foreign Agent is not 680 permitted at this time. 682 4.0 Mandatory AVPs 684 The following table describes the Diameter AVPs defined in the Mobile 685 IP extension, their AVP Code values, types, possible flag values and 686 whether the AVP MAY be encrypted. 688 +---------------------+ 689 | AVP Flag rules | 690 |----+-----+----+-----|----+ 691 AVP Section | | |SHLD| MUST|MAY | 692 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 693 -----------------------------------------|----+-----+----+-----|----| 694 MIP-Auth-Input- 338 4.8.2 Unsigned32 | M | P | | V | Y | 695 Data-Length | | | | | | 696 MIP- 339 4.8.3 Unsigned32 | M | P | | V | Y | 697 Authenticator-Length | | | | | | 698 MIP- 340 4.8.4 Unsigned32 | M | P | | V | Y | 699 Authenticator-Offset | | | | | | 700 MIP-Feature- 337 4.7 Unsigned32 | M | P | | V | Y | 701 Vector | | | | | | 702 MIP-Home-Agent- 334 4.4 Address | M | P | | V | Y | 703 Address | | | | | | 704 MIP-MN-AAA-Auth 322 4.8 Grouped | M | P | | V | Y | 705 MIP-MN-AAA-SPI 341 4.8.1 Unsigned32 | M | P | | V | Y | 706 MIP-Mobile-Node- 333 4.3 Address | M | P | | V | Y | 707 Address | | | | | | 708 MIP-Previous-FA- 336 4.6 Address | M | P | | V | Y | 709 Addr | | | | | | 710 MIP-Previous-FA- 335 4.5 OctetString| M | P | | V | Y | 711 FQDN | | | | | | 712 MIP-Reg-Request 320 4.1 OctetString| M | P | | V | Y | 713 MIP-Reg-Reply 321 4.2 OctetString| M | P | | V | Y | 715 4.1 MIP-Reg-Request AVP 717 The MIP-Reg-Request AVP (AVP Code 320) is of type OctetString and 718 contains the Mobile IP Registration Request [4] sent by the Mobile 719 Node to the Foreign Agent. 721 4.2 MIP-Reg-Reply AVP 723 The MIP-Reg-Reply AVP (AVP Code 321) is of type OctetString and 724 contains the Mobile IP Registration Reply [4] sent by the Home Agent 725 to the Foreign Agent. 727 4.3 MIP-Mobile-Node-Address AVP 729 The Mobile-Node-Address AVP (AVP Code 333) is of type Address and 730 contains the Mobile Node's Home Address. 732 4.4 MIP-Home-Agent-Address AVP 734 The Home-Agent-Addess AVP (AVP Code 334) is of type Address and 735 contains the Mobile Node's Home Agent Address. 737 4.5 MIP-Previous-FA-NAI AVP 739 The MIP-Previous-FA-FQDN AVP (AVP Code 335) is of type OctetString 740 and contains the Fully Qualified Domain Name of the Mobile Node's old 741 Foreign Agent, encoded in the UTF-8 [18] format. The Mobile Node MAY 742 include this information in the Registration Request when it moves 743 its point of attachment to a new foreign agent under the same 744 administrative domain as the old FA. 746 When this AVP is present in the AA-Mobile-Node-Request, it indicates 747 that the local Diameter server overseeing the Foreign Agent should 748 attempt to return the registration key that was previously allocated 749 to the old Foreign Agent for the Mobile Node. The registration key is 750 identified through the use of the MIP-Mobile-Node-Address AVP, which 751 MUST be present if this extension is present. 753 In many circumstances, this allows the Mobile Node to move from one 754 Foreign Agent to another within the same administrative domain 755 without having to send the request back to the Mobile Node's Home 756 Diameter Server (AAAH). 758 4.6 MIP-Previous-FA-Addr AVP 760 The MIP-Previous-FA-Addr AVP (AVP Code 336) is of type Address and 761 contains the IP Address of the Mobile Node's old Foreign Agent. The 762 Mobile Node MAY include this information in the Previous Foreign 763 Agent Notification Extension to the Mobile IP Registration Request 764 when it moves its point of attachment to a new foreign agent. 766 When this AVP is present in the AA-Mobile-Node-Request, it indicates 767 that the local Diameter server overseeing the Foreign Agent should 768 attempt to return the registration key that was previously allocated 769 to the old Foreign Agent for the Mobile Node. The registration key is 770 identified through the use of the MIP-Mobile-Node-Address AVP, which 771 MUST be present if this extension is present. 773 In many circumstances, this allows the Mobile Node to move from one 774 Foreign Agent to another within the same administrative domain 775 without having to send the request back to the Mobile Node's Home 776 Diameter Server (AAAH). 778 4.7 MIP-Feature-Vector AVP 780 The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and 781 is added with flag values set by the Foreign Agent or by the AAAF 782 owned by the same administrative domain as the Foreign Agent. The 783 Foreign Agent SHOULD include MIP-Feature-Vector AVP within the AMR 784 message it sends to the AAAF. 786 Flag values currently defined include: 787 1 Mobile-Node-Home-Address-Requested 788 2 Home-Address-Allocatable-Only-in-Home-Domain 789 4 Home-Agent-Requested 790 8 Foreign-Home-Agent-Available 791 16 MN-HA-Key-Request 792 32 MN-FA-Key-Request 793 64 FA-HA-Key-Request 794 128 Home-Agent-In-Foreign-Network 796 The flags are set according to the following rules. 798 If the mobile node includes a valid home address (i.e., not equal to 799 0.0.0.0 or 255.255.255.255) in its Registration Request, the Foreign 800 Agent zeroes the Mobile-Node-Home-Address-Requested flag in the MIP- 801 Feature-Vector AVP. 803 If the mobile node sets the home address field equal to 0.0.0.0 in 804 its Registration Request, the Foreign Agent sets the Mobile-Node- 805 Home-Address-Requested flag to one, and zeroes the Home-Address- 806 Allocatable-Only-in-Home-Domain flag in the MIP-Feature-Vector AVP. 808 If the mobile node sets the home address field equal to 809 255.255.255.255 in its Registration Request, the Foreign Agent sets 810 both the Mobile-Node-Home-Address-Requested flag and the Home- 811 Address-Allocatable-Only-in-Home-Domain flag to one in the MIP- 812 Feature-Vector AVP. 814 If the mobile node sets the home agent field equal to 0.0.0.0 in its 815 Registration Request, the Foreign Agent sets the Home-Agent-Requested 816 flag to one in the MIP-Feature-Vector AVP. 818 Whenever the Foreign Agent sets either the Home-Address-Requested 819 flag or the Home-Agent-Request flag to one, it MUST set the MN-HA- 820 Key-Request flag to one. The MN-HA-Key-Request flag is also set to 821 one if the mobile node includes a Generalized MN-HA Key Request [15] 822 extension, with the subtype set to AAA. 824 If the mobile node includes a Generalized MN-FA Key Request [15] 825 extension with the AAA subtype in its Registration Request, the 826 Foreign Agent sets the MN-FA-Key-Request flag to one in the MIP- 827 Feature-Vector AVP. 829 If the mobile node requests a home agent in the foreign network by 830 setting the home address field to all ones, and the AAAF authorizes 831 the request, the AAAF MUST set the Home-Agent-In-Foreign-Network bit 832 to one. 834 If the Foreign Agent's local policy allows it to receive AAA Session 835 Keys, and it does not have any existing keys with the Home Agent, it 836 MAY set the FA-HA-Key-Request flag. 838 The Foreign Agent MUST NOT set the Foreign-Home-Agent-Available, and 839 Home-Agent-In-Foreign-Network flag to one. 841 When the AAAF receives the AMR message, it MUST first verify that the 842 sender was an authorized Foreign Agent. The AAAF then takes any 843 actions indicated by the settings of the MIP-Feature-Vector AVP 844 flags. The AAAF then MAY set additional flags. Only the AAAF may 845 set the Foreign-Home-Agent-Available flag to one. This is done 846 according to local administrative policy. When the AAAF has finished 847 setting additional flags according to its local policy, then the AAAF 848 transmits the AMR with the possibly modified MIP-Feature-Vector AVP 849 to the AAAH. 851 4.8 MIP-MN-AAA-Auth AVP 853 The MN-AAA-Auth AVP (AVP Code 322) is of type Grouped and contains 854 some ancillary data to simplify processing of the authentication data 855 in the Mobile IP Registration Request [4] by the target AAA server. 856 Its value has the following ABNF grammar: 858 MIP-MN-AAA-Auth = ma-spi authinlen authlen authoffset 859 ma-spi = ; MIP-MN-AAA-SPI, See Section 4.8.1 860 authinlen = ; MIP-Auth-Input-Data-Length, / 861 ; See Section 4.8.2 862 authlen = ; MIP-Authenticator-Length, / 863 ; See Section 4.8.3 864 authoffset = ; MIP-Authenticator-Offset, / 865 ; See Section 4.8.4 867 +---------------------------------------------------------------+ 868 | AVP Header (AVP Code = 322) | 869 +---------------------------------------------------------------+ 870 | MIP-MN-AAA-SPI AVP | 871 +---------------------------------------------------------------+ 872 | MIP-Auth-Input-Data-Length AVP | 873 +---------------------------------------------------------------+ 874 | MIP-Authenticator-Length AVP | 875 +---------------------------------------------------------------+ 876 | MIP-Authenticator-Offset AVP | 877 +---------------------------------------------------------------+ 879 4.8.1 MIP-MN-AAA-SPI AVP 881 The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and 882 indicates the algorithm by which the targeted AAA server (AAAH) 883 should attempt to validate the Authenticator computed by the mobile 884 node over the Registration Request data. 886 4.8.2 MIP-Auth-Input-Data-Length AVP 888 The MIP-Auth-Input-Data-Length AVP (AVP Code 338) is of type 889 Unsigned32 and contains the length, in bytes, of the Registration 890 Request data (data portion of MIP-Reg-Request AVP) that should be 891 used as input to the algorithm (indicated by the MN-AAA-SPI AVP) used 892 to determine whether the Authenticator Data supplied by the Mobile 893 Node is valid. 895 4.8.3 MIP-Authenticator-Length AVP 897 The MIP-Authenticator-Length AVP (AVP Code 339) is of type Unsigned32 898 and contains the length of the authenticator to be validated by the 899 targeted AAA server (i.e., AAAH). 901 4.8.4 MIP-Authenticator-Offset AVP 903 The MIP-Authenticator-Offset AVP (AVP Code 340) is of type Unsigned32 904 and contains the offset into the Registration Request Data, of the 905 authenticator to be validated by the targeted AAA server (i.e., 906 AAAH). 908 5.0 Key Distribution Center 909 The mobile node and mobility agents use registration keys to compute 910 authentication extensions applied to registration messages, as 911 defined in [4]: Mobile-Foreign, Foreign-Home and Mobile-Home. If 912 registration keys are requested the AAA server(s) MUST create them 913 after the Mobile Node is successfully authenticated and authorized. 915 The keys destined for each mobility entity are encrypted either using 916 the secret shared with the entity [1], or via its public key [9], as 917 indicated by the relevant security association. If the AAAH does not 918 communicate directly with the Foreign Agent, those keys are encrypted 919 using the security association shared with the AAAF. The 920 Authorization-Lifetime AVP contains the number of seconds before 921 registration keys destined for the Home Agent and/or Foreign Agent 922 expire. Absence or the AVP, or a value of zero indicates infinity 923 (no timeout). 925 AAA support for key distribution departs slightly from the existing 926 SPI usage, as described in [4]. The SPI values are used as key 927 identifiers, meaning that each registration key has its own SPI 928 value; nodes that share a key also share an SPI. If no preferred SPI 929 value is indicated the registration keys the foreign agent needs, the 930 AAA server MAY generate SPI values for the Mobility Agents as opposed 931 to the receiver choosing its own SPI value. For example, suppose a 932 Mobile Node and a Foreign Agent share a key that was generatied by 933 AAAH with a corresponding SPI value of 37,496. All Mobile-Foreign 934 Authentication extensions will be computed by either entity (in this 935 example) using the shared key and MUST include the SPI value of 936 37,496. 938 Once the registration keys have been distributed, subsequent Mobile 939 IP registrations need not invoke the AAA infrastructure until the 940 keys expire. These registrations MUST include the Mobile-Home 941 authentication extension. In addition, subsequent registrations MUST 942 also include Mobile-Foreign authentication extension if the Mobile- 943 Foreign key was generated and distributed by AAA; similarly for 944 subsequent use of the Foreign-Home authentication extensions. 946 Each registration key that is generated by AAA will generally be 947 distributed to two parties; for instance, a Mobile-Foreign key goes 948 to both a mobile node and a foreign agent. The methods by which the 949 key is encoded will depend upon the security associations available 950 to the AAA server and each recipient of the key. These methods will 951 often be different for the two recipients, so that the registration 952 key under consideration has to be encoded twice. 954 See sections 6.1 and 6.2 for details about the format of the AVPs 955 used to distribute the registration keys. 957 5.1 Distributing the Mobile-Home Registration Key 959 If the mobile node does not have a Mobile-Home registration key, then 960 the AAAH is likely to be the only entity trusted that is available to 961 the mobile node. Thus, the AAAH has to generate the Mobile-Home 962 registration key, and encode it for eventual consumption by the 963 mobile node and home agent. 965 If the home agent is in the home domain, then AAAH can directly 966 encode the Mobile-Home registration key into a MIP-HA-to-MN-Key AVP 967 and include that AVP in the HAR message for delivery to the home 968 agent. 970 If, on the other hand, the home agent is to be allocated in the 971 visited domain, the AAAH does not transmit the HAR to the home agent. 972 Instead, AAAH has to include the MIP-HA-to-MN-Key AVP in the AMR 973 message which it sends to the AAAF. In this latter case, the 974 Mobile-Home registration key is encoded into MIP-HA-to-MN-Key AVP 975 using the method indicated by the security association between the 976 AAAF and the AAAH. When the AAAF receives the AMR, it first allocates 977 a home agent, and then creates a HAR message for that home agent. 978 After the AAAF decodes the registration key, it re-encodes the key 979 into a new MIP-HA-to-MN-Key AVP which is to be included within the 980 HAR message. 982 The AAAH also has to arrange for the key to be delivered to the 983 mobile node. Unfortunately, the AAA server only knows about Diameter 984 messages and AVPs, and the mobile node only knows about Mobile IP 985 messages and extensions[4]. The AAA server has to rely on a mobility 986 agent (that also understands Diameter) to transfer the key into a 987 Mobile IP MN-HA Key Reply extension to the Registration Reply 988 message. This mobility agent (actually, the mobile node's home 989 agent) can format the Reply message and extensions correctly for 990 eventual delivery to the mobile node, by way of an AMA message sent 991 to the appropriate foreign agent in the visited domain. That foreign 992 agent will use the information in the MIP-Reg-Reply AVP to create a 993 Mobile IP Registration Reply message, containing the MN-HA Key Reply 994 extension, and transmit it to the mobile node. 996 For this purpose, AAAH encodes the Mobile-Home registration key into 997 a MIP-MN-to-HA-Key AVP, using its security association with the 998 mobile node. If the home agent is in the home domain, AAAH puts the 999 MIP-MN-to-HA-Key AVP into the HAR message. Otherwise, the AAAH puts 1000 the MIP-MN-to-HA-Key AVP into the AMR message which will be sent back 1001 to AAAF. When AAAF creates the HAR message for the home agent in the 1002 visited domain, and decodes the registration key in the MIP-HA-to- 1003 MN-Key AVP from the AVP received from AAAH, AAAF then recodes the 1004 registration key into a new MIP-HA-to-MN-Key AVP which is to be 1005 included as part of the HAR message. In either case, the home agent 1006 creates a Registration Reply with the MN-HA Key Reply extension, and 1007 formats the reply data into a MIP-Reg-Rep-AVP for delivery in a HAA 1008 message to the AAA server. After the HAA message is parsed by the AAA 1009 server, the AMA message containing the MIP-Reg-Rep AVP will 1010 eventually be received by the attendant (i.e., the foreign agent). 1011 The foreign agent can then use that AVP to recreate a Registration 1012 Reply message, containing the MN-HA Key Reply extension, for delivery 1013 to the mobile node. 1015 In summary, the AAAH generates the Mobile-Home registration key and 1016 encodes it into a MIP-HA-to-MN-Key AVP and a MIP-MN-to-HA-Key AVP. 1017 These AVPs are delivered to a home agent by including them in a HAR 1018 message sent from either AAAH or AAAF. The home agent decodes the key 1019 for its own use. The home agent also copies the encoded registration 1020 key from the MIP-MN-to-HA-Key AVP into a MN-HA Key Reply extension 1021 appended to the Mobile IP Registration Reply message. This 1022 Registration Reply message MUST also include the Mobile-Home 1023 authentication extension, created using the newly allocated Mobile- 1024 Home registration key. The home agent then encodes the Registration 1025 Reply message and extensions into a MIP-Reg-Reply AVP included as 1026 part of the HAA message to be sent back to the AAA server. 1028 5.2 Distributing the Mobile-Foreign Registration Key 1030 The Mobile-Foreign registration key is also generated by AAAH (upon 1031 request), so that it can be encoded into a MIP-MN-to-FA-Key AVP and 1032 copied by the home agent into a "General MN-FA Key Reply Extension" 1033 extension [15] to the Mobile IP Registration Reply message. Since the 1034 foreign agent is in the same administrative domain as AAAF, the 1035 sequence of events for handling the MIP-FA-to-MN-Key AVP is similar 1036 to the way the MIP-HA-to-MN-Key AVP is handled when the home agent is 1037 allocated in the visited domain. Most of the other considerations for 1038 distributing the Mobile-Foreign registration key are also similar. 1040 When the home agent is in the home domain, AAAH includes the MIP-MN- 1041 to-FA-Key AVP in the HAR message. Otherwise, AAAH includes the MIP- 1042 MN-to-FA-Key AVP in the AMR message to be sent back to the AAAF. In 1043 the latter case, AAAF sends the HAR message to the (newly allocated) 1044 home agent. 1046 In either case, the home agent decodes the key, and recodes it into 1047 the key reply extension to the Mobile IP registration message. Then 1048 the home agent (as before) copies the Registration Reply message into 1049 the MIP-Reg-Reply AVP and places the result (possibly also containing 1050 the MN-HA Key Reply extension as in section 1.4.1) into the HAA 1051 message to be sent back to the AAA server. The home agent MUST also 1052 append a Foreign-Home authentication extension to the Registration 1053 Reply message, using the newly allocated Foreign-Home registration 1054 key. 1056 When the home agent is in the home domain, AAAH receives the HAA, and 1057 then includes the MIP-Reg-Reply AVP in the AMA message to be sent to 1058 AAAF. Otherwise, AAAF receives the HAA, and inserts it into an AMA 1059 message to be sent to the foreign agent. 1061 AAAH also has to make the Mobile-Foreign registration key available 1062 to AAAF. It does this by encoding the key into a MIP-FA-to-MN-Key 1063 AVP, using its security association with AAAF, and placing the 1064 results in the AMA. Then the AAAF decodes the registration key, and 1065 recodes it into a newly formulated MIP-FA-to-MN-Key AVP which is to 1066 be sent to the foreign agent in the AMA message containing the MIP- 1067 Reg-Reply AVP from the home agent. 1069 5.3 Distributing the Foreign-Home Registration Key 1071 If the home agent is in the home domain, then AAAH has to generate 1072 the Foreign-Home registration key. Otherwise, it is generated by 1073 AAAF. 1075 In the former case, AAAH encodes the registration key into a MIP-HA- 1076 to-FA-Key AVP and includes that AVP as part of the HAR message sent 1077 to the home agent, and waits for the HAA message to be returned. 1079 Whether or not AAAH sends the HAR message, it also further encodes 1080 the same registration key and puts it into a MIP-FA-to-HA-Key AVP 1081 included as part of the AMA message to be transmitted back to AAAF. 1083 If the home agent is in the visited domain, the AAAH includes the 1084 MIP-HA-to-FA-Key AVP as part of the AMR also. In this case, AAAF has 1085 to decode the Foreign-Home registration key and include it as part of 1086 the HAR message to be sent to the (newly allocated) home agent. 1088 In either case, AAAF sends a AMA message, containing a MIP-Reg-Reply 1089 AVP and the MIP-FA-to-HA-Key AVP, to the foreign agent. First, the 1090 foreign agent recreates the necessary Registration Reply message from 1091 the AMA message. Then the foreign agent recovers the Foreign-Home 1092 registration key, using its security association with AAAF. The 1093 foreign agent MUST then use this key to create a Mobile-Foreign 1094 authentication extension to the Registration Reply message. 1096 5.4 Key Distribution Example 1097 Figure 6 provides an example of subsequent Mobile IP message 1098 exchange, assuming that AAAH distributed registration keys for all 1099 three MN-FA, FA-HA and HA-MN authentication extensions. 1101 Mobile Node Foreign Agent Home Agent 1102 ----------- ------------- ---------- 1104 Reg-Req(MN-HA-Auth, MN-FA-Auth)--------> 1106 Reg-Req(MN-HA-Auth, FA-HA-Auth)--------> 1108 <--------Reg-Rep(MN-HA-Auth, FA-HA-Auth) 1110 <--------Reg-Rep(MN-HA-Auth, MN-FA-Auth) 1112 Figure 6: Mobile IP Message Exchange 1114 6.0 Key Distribution Center (KDC) AVPs 1116 The Mobile-IP protocol defines a set of security associations shared 1117 between the Mobile Node, Foreign Agent and Home Agents. These three 1118 security associations (Mobile-Home, Mobile-Foreign, and Foreign- 1119 Home), can be dynamically created by the AAAH. This requires that the 1120 AAAH create Mobile-IP Registration Keys, and that these keys be 1121 distributed to the three mobile entities, via the Diameter Protocol. 1122 AAA servers supporting the Diameter Mobile IP Extension MUST 1123 implement the KDC AVPs defined in this document. In other words, AAA 1124 servers MUST be able to create three registration keys: the Mobile- 1125 Home, Mobile-Foreign, and Foreign-Home keys. 1127 Each of these keys is encrypted two different ways, as needed for 1128 each key recipient. The mobile node and home agent registration keys 1129 are sent to the Home Agent, while the foreign agent's keys are sent 1130 to the foreign agent via the AAAF. This leads to six different AVPs, 1131 since there are three keys, and each one has to be able to be 1132 encrypted in two different ways. 1134 The names of the KDC AVPs indicate the two entities sharing the 1135 security association defined by the encrypted key material; the 1136 intended receiver of the AVP is the first named entity. So, for 1137 instance, the MIP-MN-to-HA-Key AVP contains the Mobile-Home key 1138 encrypted in a way that allows it to be recovered by the mobile node. 1140 If strong authentication and confidentiality of the registration keys 1141 is required, it is recommended that the strong security extension [9] 1142 be used. 1144 The following table describes the Diameter AVPs defined in the Mobile 1145 IP extension, their AVP Code values, types, possible flag values and 1146 whether the AVP MAY be encrypted. 1148 +---------------------+ 1149 | AVP Flag rules | 1150 |----+-----+----+-----|----+ 1151 AVP Section | | |SHLD| MUST|MAY | 1152 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 1153 -----------------------------------------|----+-----+----+-----|----| 1154 MIP-FA-to-MN-Key 326 6.2.1 Grouped | M | P | | V | Y | 1155 MIP-FA-to-HA-Key 328 6.2.2 Grouped | M | P | | V | Y | 1156 MIP-HA-to-FA-Key 329 6.2.3 Grouped | M | P | | V | Y | 1157 MIP-HA-to-MN-Key 332 6.2.4 Grouped | M | P | | V | Y | 1158 MIP-MN-to-FA-Key 325 6.1.1 OctetString| M | P | | V | Y | 1159 MIP-MN-to-HA-Key 331 6.1.2 OctetString| M | P | | V | Y | 1160 MIP-Peer-SPI 342 6.2.5 Unsigned32 | M | P | | V | Y | 1161 MIP-FA-MN- 324 6.3 Unsigned32 | M | P | | V | Y | 1162 Preferred-SPI | | | | | | 1163 MIP-FA-HA- 327 6.4 Unsigned32 | M | P | | V | Y | 1164 Preferred-SPI | | | | | | 1165 MIP-Session-Key 343 6.2.6 OctetString| M | P | | V | Y | 1167 6.1 Mobile Node Registration Keys 1169 When the AAAH acts as a Key Distribution Center, and it is determined 1170 that keying material is to be created for Mobile Nodes, the AAAH 1171 creates the keys and encodes them in the MIP-MN-to-FA-Key and MIP- 1172 MN-to-HA-Key AVPs as opaque data. The actual format of the AVP value 1173 is described in [15], and would contains the data immediately 1174 following the Mobile IP extension header. 1176 The Mobile IP key described in [15] refers to the AAA SPI, which MUST 1177 be set to the value the AAAH shares with the Mobile Node. The Key 1178 Lifetime field is set to the same value as the one found in the 1179 Authorization-Lifetime AVP. 1181 6.1.1 MIP-MN-to-FA-Key AVP 1183 The MIP-MN-to-FA-Key AVP (AVP Code 325) is of type OctetString, and 1184 contains the Keying material described in the "Unsolicited MN-FA Key 1185 from AAA Subtype" in [15]. The FA SPI field of the data structure in 1186 [15] MUST be set to the same value as the Peer-SPI AVP within the 1187 FA-to-MN-Key AVP. 1189 6.1.2 MIP-MN-to-HA-Key AVP 1191 The MIP-MN-to-HA-Key AVP (AVP Code 331) is of type OctetString, and 1192 contains the Keying material described in the "Unsolicited MN-HA Key 1193 from AAA Subtype" in [15]. The HA SPI field of the data structure in 1194 [15] MUST be set to the same value as the Peer-SPI AVP within the 1195 HA-to-MN-Key AVP. 1197 6.2 Mobility Agent Session Keys 1199 The Mobility Agent session keys are the keys created by a Diameter 1200 server, which it distributes to Foreign and Home Agents, acting as 1201 Diameter clients. These session keys, described below, are of type 1202 Grouped, and therefore their value have the following ABNF format: 1204 Mobility Agent Session Key AVP = Peer-SPI Session-Key 1205 Peer-SPI = ; MIP-Peer-SPI, See Section 6.2.5 1206 Session-Key = ; MIP-Session-Key, See Section 6.2.6 1208 The MIP-Peer-SPI AVP contains the Security Parameter Index, which the 1209 Mobility Agent MUST use to refer to the Key contained in the MIP- 1210 Session-Key AVP. 1212 +---------------------------------------------------------------+ 1213 | AVP Header (AVP Code = see below) | 1214 +---------------------------------------------------------------+ 1215 | MIP-Peer-SPI AVP | 1216 +---------------------------------------------------------------+ 1217 | MIP-Session-Key AVP | 1218 +---------------------------------------------------------------+ 1220 6.2.1 MIP-FA-to-MN-Key AVP 1222 The MIP-FA-to-MN-Key AVP (AVP Code 326) is of type Grouped, and 1223 contains the Foreign Agent's session key, which it shares with the 1224 Mobile Node. Its format is described in Section 6.2. 1226 6.2.2 MIP-FA-to-HA-Key AVP 1228 The MIP-FA-to-HA-Key AVP (AVP Code 328) is of type Grouped, and 1229 contains the Foreign Agent's session key, which it shares with the 1230 Home Agent. Its format is described in Section 6.2. 1232 6.2.3 MIP-HA-to-FA-Key AVP 1233 The MIP-HA-to-FA-Key AVP (AVP Code 329) is of type Grouped, and 1234 contains the Home Agent's session key, which it shares with the 1235 Foreign Agent. Its format is described in Section 6.2. 1237 6.2.4 MIP-HA-to-MN-Key AVP 1239 The MIP-HA-to-MN-Key AVP (AVP Code 332) is of type Grouped, and 1240 contains the Home Agent's session key, which it shares with the 1241 Mobile Node. Its format is described in Section 6.2. 1243 6.2.5 MIP-Peer-SPI AVP 1245 The MIP-Peer-SPI AVP (AVP Code 342) is of type Unsigned32, and 1246 contains the Security Parameter Index to use to reference the key in 1247 the associated MIP-Session-Key AVP. 1249 6.2.6 MIP-Session-Key AVP 1251 The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and 1252 contains the Session Key to be used between two Mobile IP entities. 1254 6.3 MIP-FA-MN-Preferred-SPI AVP 1256 The MIP-FA-MN-Preferred-SPI AVP (AVP Code 324) is of type Unsigned32 1257 and is sent in the AA-Mobile-Node-Request by the Foreign Agent. The 1258 AVP contains the SPI that the Foreign Agent would prefer to have 1259 assigned by the AAAH in the MIP-FA-to-MN-Key AVP. 1261 6.4 MIP-FA-HA-Preferred-SPI AVP 1263 The MIP-FA-HA-Preferred-SPI AVP (AVP Code 327) is of type Unsigned32 1264 and is sent in the AA-Mobile-Node-Request by the Foreign Agent. The 1265 AVP contains the SPI that the Foreign Agent would prefer to have 1266 assigned by the AAAH in the MIP-FA-to-HA-Key AVP. 1268 7.0 Accounting Considerations 1270 This section contains the AVPs defined in this extension that are to 1271 be present in the Accounting-Request and optionally in the 1272 Accounting-Answer messages, defined in [12]. 1274 ::= { MIP-Mobile-Node-Address } 1275 { MIP-Home-Agent-Address } 1276 [ MIP-Previous-FA-NAI ] 1277 [ MIP-Previous-FA-Address ] 1278 [ MIP-Feature-Vector ] 1280 8.0 Interactions with Resource Management 1282 The Resource Management extension [17] provides the ability for a 1283 Diameter node to query a peer for session state information. The 1284 document states that service-specific extensions are responsible for 1285 specifying what AVPs are to be present in the Resource-Token [17] 1286 AVP. 1288 In addition to the AVPs listed in [17], the Resource-Token with the 1289 Extension-Id AVP set to four (4) MUST include the MIP-Mobile-Node- 1290 Address and the MIP-Home-Agent-Address AVP. 1292 9.0 AVP Table 1294 The following table presents the AVPs defined in this document, and 1295 specifies in which Diameter messages they MAY, or MAY NOT be present. 1296 Note that AVPs that can only be present within a Grouped AVP are not 1297 represented in this table. 1299 The table uses the following symbols: 1300 0 The AVP MUST NOT be present in the message. 1301 0+ Zero or more instances of the AVP MAY be present in the 1302 message. 1303 0-1 Zero or one instance of the AVP MAY be present in the 1304 message. 1305 1 One instance of the AVP MUST be present in the message. 1307 +-----------------------------+ 1308 | Command-Code | 1309 |-----+-----+-----+-----+-----+ 1310 Attribute Name | AMR | AMA | HAR | HAA | HAI | 1311 ------------------------------|-----+-----+-----+-----+-----| 1312 Authorization-Lifetime | 1 | 1 | 1 | 1 | 1 | 1313 Destination-FQDN | 0+ | 1 | 0+ | 1 | 1 | 1314 Destination-Realm | 1 | 1 | 1 | 1 | 1 | 1315 Error-Reporting-FQDN | 0 | 0+ | 0 | 0+ | 0 | 1316 Extension-Id | 1 | 1 | 1 | 1 | 1 | 1317 Integrity-Check-Value | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 1318 MIP-FA-to-HA-Key | 0 | 0-1 | 0-1 | 0-1 | 0 | 1319 MIP-FA-to-MN-Key | 0 | 0-1 | 0-1 | 0-1 | 0 | 1320 MIP-Feature-Vector | 0-1 | 0 | 0 | 0 | 0 | 1321 MIP-FA-HA-Preferred-SPI | 0-1 | 0 | 0 | 0 | 0 | 1322 MIP-FA-MN-Preferred-SPI | 0-1 | 0 | 0 | 0 | 0 | 1323 MIP-HA-to-FA-Key | 0 | 0 | 0-1 | 0 | 0 | 1324 MIP-HA-to-MN-Key | 0 | 0 | 0-1 | 0 | 0 | 1325 MIP-Home-Agent-Address | 0-1 | 0-1 | 0 | 0-1 | 0-1 | 1326 MIP-MN-AAA-Auth | 1 | 0 | 0 | 0 | 0 | 1327 MIP-MN-to-FA-Key | 0 | 0 | 0-1 | 0 | 0 | 1328 MIP-MN-to-HA-Key | 0 | 0-1 | 0-1 | 0 | 0 | 1329 MIP-Mobile-Node-Address | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 1330 MIP-Previous-FA-Address | 0-1 | 0 | 0 | 0 | 0 | 1331 MIP-Previous-FA-NAI | 0-1 | 0 | 0 | 0 | 0 | 1332 MIP-Reg-Reply | 0 | 0-1 | 0 | 0-1 | 0 | 1333 MIP-Reg-Request | 1 | 0 | 1 | 0 | 0 | 1334 Origin-FQDN | 1 | 1 | 1 | 1 | 1 | 1335 Origin-Realm | 1 | 1 | 1 | 1 | 1 | 1336 Proxy-State | 0+ | 0+ | 0+ | 0+ | 0+ | 1337 Result-Code | 0 | 1 | 0 | 1 | 0 | 1338 Route-Record | 0+ | 0+ | 0+ | 0+ | 0+ | 1339 Session-Id | 1 | 1 | 1 | 1 | 1 | 1340 Session-Timeout | 0 | 1 | 1 | 1 | 1 | 1341 User-Name | 1 | 0 | 1 | 0 | 0 | 1342 ------------------------------|-----+-----+-----+-----+-----| 1344 10.0 Acknowledgements 1346 The authors would like to thank Nenad Trifunovic and Pankaj Patel for 1347 their participation in the Document Reading Party, to Erik Guttman 1348 for his very useful proposed text, and to Tony Johansson for the 1349 proposed text AND being in the doc reading party. The authors would 1350 also like to thank the participants of 3GPP2's TSG-P working group 1351 for their valuable feedback. 1353 11.0 IANA Considerations 1355 The command codes defined in Section 2.0 are values taken from the 1356 Command-Code [1] address space and extended in [9], [12] and [14]. 1357 IANA should record the values as defined in Section 2.0. 1359 The Result-Code values defined in Section 3.0 are error codes as 1360 defined in [1] and extended in [9], [12] and [14]. They correspond to 1361 error values specific to the Mobile IP extension. IANA should record 1362 the values as defined in Section 3.0. 1364 The AVPs defined in sections 4.0 and 6.0 were allocated from the AVP 1365 numbering space defined in [1], and extended in [9], [12] and [14]. 1366 IANA should record the values as defined in Sections 4.0 and 6.0. 1368 12.0 Security Considerations 1370 This specification describes the Diameter extension necessary to 1371 authenticate and authorize a Mobile IP Mobile Node. The 1372 authentication algorithm used is dependent upon the transforms 1373 available by the Mobile IP protocol, and [5]. This specification also 1374 defines a method by which the home Diameter server can create and 1375 distribute registration keys to be used to authenticate Mobile IP 1376 registration messages. The keys are distributed in an encrypted 1377 format through the Diameter protocol, and SHOULD be encrypted using 1378 the methods defined in [9]. 1380 13.0 References 1382 [1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "Diameter Base 1383 Protocol", draft-ietf-aaa-diameter-01.txt, IETF work in pro- 1384 gress, March 2001. 1386 [2] Calhoun, Zorn, Pan, Akhtar, "Diameter Framework", draft-ietf- 1387 aaa- diameter-framework-01.txt, IETF work in progress, March 1388 2001. 1390 [3] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, 1391 Authorization, and Accounting Requirements". RFC 2977. October 1392 2000. 1394 [4] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. 1396 [5] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response Exten- 1397 sions". RFC 3012. November 2000. 1399 [6] B. Aboba, M. Beadles "The Network Access Identifier." RFC 2486. 1400 January 1999. 1402 [7] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", 1403 RFC 2477, January 1999. 1405 [8] P. Calhoun, C. Perkins, "Mobile IP Network Address Identifier 1406 Extension", RFC 2794, March 2000. 1408 [9] P. Calhoun, W. Bulley, S. Farrell, "Diameter Strong Security 1409 Extensions", draft-calhoun-diameter-strong-crypto-06.txt, IETF 1410 work in progress, February 2001. 1412 [10] Kent, Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 1413 2406, November 1998. 1415 [11] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1416 Levels", BCP 14, RFC 2119, March 1997. 1418 [12] J. Arkko, P. Calhoun, P. Patel, G. Zorn, "Diameter Accounting 1419 Extension", draft-ietf-aaa-diameter-accounting-01.txt, IETF work 1420 in progress, March 2001. 1422 [13] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing 1423 for Message Authentication. RFC 2104, February 1997. 1425 [14] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASREQ 1426 Extension", draft-ietf-aaa-diameter-nasreq-01.txt, IETF work in 1427 progress, March 2001. 1429 [15] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile IP", 1430 draft-calhoun-mobileip-aaa-key-03.txt, IETF work in progress, 1431 January 2001. 1433 [16] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA", 1434 draft-hiller-cdma2000-aaa-01.txt, IETF work in progress, June 1435 2000. 1437 [17] P. Calhoun, "Diameter Resource Management", draft-calhoun- 1438 diameter-res-mgmt-06.txt, IETF Work in Progress, February 2001. 1440 [18] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 1441 2279, January 1998. 1443 14.0 Authors' Addresses 1445 Questions about this memo can be directed to: 1447 Pat R. Calhoun 1448 Network and Security Research Center, Sun Labs 1449 Sun Microsystems, Inc. 1450 15 Network Circle 1451 Menlo Park, California, 94025 1452 USA 1454 Phone: +1 650-786-7733 1455 Fax: +1 650-786-6445 1456 E-mail: pcalhoun@eng.sun.com 1458 Charles E. Perkins 1459 Nokia Research Center 1460 313 Fairchild Drive 1461 Mountain View, California 94043 1462 USA 1464 Phone: +1 650-625-2986 1465 Fax: +1 650-625-2502 1466 E-Mail: charliep@iprg.nokia.com 1468 15.0 Full Copyright Statement 1470 Copyright (C) The Internet Society (2001). All Rights Reserved. 1472 This document and translations of it may be copied and furnished to 1473 others, and derivative works that comment on or otherwise explain it 1474 or assist in its implementation may be prepared, copied, published 1475 and distributed, in whole or in part, without restriction of any 1476 kind, provided that the above copyright notice and this paragraph are 1477 included on all such copies and derivative works. However, this docu- 1478 ment itself may not be modified in any way, such as by removing the 1479 copyright notice or references to the Internet Society or other 1480 Internet organizations, except as needed for the purpose of develop- 1481 ing Internet standards in which case the procedures for copyrights 1482 defined in the Internet Standards process must be followed, or as 1483 required to translate it into languages other than English. The lim- 1484 ited permissions granted above are perpetual and will not be revoked 1485 by the Internet Society or its successors or assigns. This document 1486 and the information contained herein is provided on an "AS IS" basis 1487 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 1488 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 1489 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1490 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1491 FITNESS FOR A PARTICULAR PURPOSE. 1493 16.0 Expiration Date 1495 This memo is filed as and 1496 expires in August 2001.