idnits 2.17.1 draft-giaretta-mip6-authorization-eap-00.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 299 has weird spacing: '...AN) and forwa...' -- 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 (February 2004) is 7374 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) -- Looks like a reference, but probably isn't: 'Service-Options' on line 1046 -- Looks like a reference, but probably isn't: 'Home-Agent-Address' on line 1596 -- Looks like a reference, but probably isn't: 'Home-Address' on line 1608 -- Looks like a reference, but probably isn't: 'Interface-Identifier' on line 407 -- Looks like a reference, but probably isn't: 'HA-Features' on line 1607 -- Looks like a reference, but probably isn't: 'Interface-ID' on line 1608 -- Looks like a reference, but probably isn't: 'Policy' on line 1633 -- Looks like a reference, but probably isn't: 'Authorization-Lifetime-AVP' on line 821 -- Looks like a reference, but probably isn't: 'IKE-Bootstrap-Info' on line 1613 == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-07 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-09) exists of draft-ietf-eap-rfc2284bis-07 == Outdated reference: A later version (-05) exists of draft-ietf-pppext-eap-ttls-03 -- Possible downref: Normative reference to a draft: ref. '4' ** Obsolete normative reference: RFC 3041 (ref. '5') (Obsoleted by RFC 4941) -- No information found for draft-le-aaa-diameter- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 2409 (ref. '8') (Obsoleted by RFC 4306) == Outdated reference: A later version (-18) exists of draft-ietf-pana-pana-02 -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-01 Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MIP6 Working Group G. Giaretta 2 Internet Draft I. Guardini 3 Expires: August 2004 E. Demaria 4 TILab 5 February 2004 7 MIPv6 Authorization and Configuration based on EAP 8 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. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This draft defines an architecture, and related protocols, for 34 performing dynamic Mobile IPv6 authorization and configuration 35 relaying on a AAA infrastructure. The necessary interaction between 36 the AAA server of the home provider and the mobile node is realized 37 using EAP, exploiting the capability of some EAP methods to convey 38 generic information items together with authentication data. This 39 approach has the advantage that the access equipment acts just as a 40 pass-through for EAP messages and therefore does not play any active 41 role in the Mobile IPv6 negotiation procedure, which makes the 42 solution easier to deploy and maintain. 43 The same approach can be ported also to environments performing user 44 authentication with methods other than EAP (e.g. GSM, UMTS or CDMA), 45 by simply using PANA with null authentication to undertake MIPv6 46 negotiation after the user has gained IP access to the network. 48 Table of Contents 50 1. Introduction................................................2 51 2. Protocol Overview...........................................3 52 3. Detailed Description of the Protocol........................6 53 3.1 Mobile Node bootstrap....................................7 54 3.2 Management of reauthentication events...................15 55 3.3 Session Termination.....................................16 56 4. Home Agent considerations..................................19 57 4.1 Service Authorization Cache (SAC).......................19 58 4.2 Management of Binding Cache entries.....................19 59 5. Protocol Applicability in Cellular Networks................20 60 6. New Messages and Attributes................................24 61 6.1 New EAP-TLVs............................................24 62 6.2 New Diameter messages and AVPs..........................29 63 7. Open Issues................................................31 64 8. Security Considerations....................................32 65 Acknowledgments.................................................32 66 References......................................................32 67 Appendix A - Home Agent allocation in a foreign domain..........34 68 Authors' Addresses..............................................37 69 Intellectual Property Statement.................................37 71 1. Introduction 73 Mobile IPv6 [1] requires that Mobile Nodes (MNs) and Home Agents 74 (HAs) share a set of configuration parameters: for example, the MN 75 must know its Home Address, the Home Agent Address and the 76 cryptographic material needed to protect MIPv6 signaling (e.g. shared 77 keys or certificates to setup an IPsec security association). MIPv6 78 base protocol does not specify any method to automatically acquire 79 this information; which means that network administrators are 80 normally required to manually set configuration data on MNs and HAs. 82 Manual configuration of Home Agents and Mobile Nodes also works as an 83 implicit method for Mobile IPv6 authorization, because only the users 84 that have been administratively enabled on a specific Home Agent are 85 allowed to exploit Mobile IPv6 and its features. 87 However, in a large network (e.g. the network of a mobile operator), 88 which may include millions of users and many Home Agents, the 89 operational and administrative burden of this procedure may easily 90 become overwhelming. In addition, the extensive use of manual and 91 static configurations limits the flexibility and reliability of the 92 system, in that it is not possible to dynamically assign the HA when 93 the user enters the network, which would help to optimize performance 94 and resource utilization (e.g. assignment of the HA closest to the 95 MN's point of attachment). 97 With the objective to solve the limitations described above, this 98 draft defines an architecture, and related protocols, for performing 99 dynamic Mobile IPv6 authorization and configuration relaying on a AAA 100 infrastructure. The necessary interaction between the AAA server of 101 the home provider and the mobile node is realized using EAP, 102 exploiting the capability of some EAP methods, and in particular 103 PEAPv2 [2], to convey generic information items together with 104 authentication data. 106 The suggested approach can be deployed, with no changes to existing 107 access equipment (Access Points, Access Gateways, etc.), in any 108 network supporting EAP-based authentication (e.g. IEEE 802.1x 109 Wireless LANs), but can be ported also to environments performing 110 user authentication with methods other than EAP (e.g. GSM, UMTS or 111 CDMA), by simply using PANA [9] with null authentication to undertake 112 MIPv6 negotiation after the user has gained IP access to the network. 114 2. Protocol Overview 116 The basic idea behind the solution proposed herewith is to perform 117 Mobile IPv6 authorization and configuration during the authentication 118 procedure undertaken by the Mobile Node to gain network access. 119 In particular, this draft defines a method to: 121 - explicitly authorize the use of Mobile IPv6 based on the service 122 profile of the user, its position within the network, etc. 124 - dynamically allocate a Home Agent to the Mobile Node; 126 - dynamically configure Mobile IPv6 start-up parameters on both the 127 Home Agent and the Mobile Node. These parameters include the Home 128 Address and the cryptographic material needed to set-up the IPsec 129 Security Association used to protect Mobile IPv6 signaling (i.e. 130 Binding Updates and Binding Acknowledges); 132 - allow the MN to negotiate additional Mobile IPv6 service options, 133 such as the possibility to use multiple access networks at the 134 same time (i.e. registration of multiple Care-of Addresses), the 135 assignment of a HA within the visited domain, etc. 137 Figure 1 shows the overall architecture of the solution proposed in 138 this draft. The central element of the architecture is the AAA server 139 of the Home Domain (i.e. AAAH), which interacts with both the MN and 140 the selected HA to perform service authorization and configuration. 142 AAA 143 Client 144 IEEE 802.1x +------+ RADIUS 145 or PANA | | or Diameter 146 +--------+ /---------------TLS Tunnel------------------\ +--------+ 147 | Mobile |/ <------------Authentication---------------> \| AAAH | 148 | Node |\ <--MIPv6 authorization and configuration--> /| Server | 149 +--------+ \-------------------------------------------/ +--------+ 150 | | /\ 151 +------+ /||\ 152 Router || 153 or AP Diameter || 154 (pass-through) HA Appl. || 155 \||/ 156 \/ 157 +--------+ 158 | Home | 159 | Agent | 160 +--------+ 162 Figure 1 - Solution architecture 164 The solution can be deployed in any access network where EAP [3] and, 165 in particular, PEAPv2 [2] are used to perform user authentication; 166 this is because the messages exchanged between the MN and the AAAH 167 server to achieve dynamic Mobile IPv6 authorization and configuration 168 are carried in EAP-TLVs (i.e. information fields in the form of Type 169 Length Value) delivered within the TLS tunnel created in the phase 1 170 of PEAPv2. Anyway, the same approach could be ported to any other EAP 171 method having the capability to establish a secure tunnel between the 172 MN and the AAAH server (e.g. EAP-TTLS [4]). 174 Figure 2 shows an overview of the procedure defined to handle MIPv6 175 bootstrap on the Mobile Node. The whole procedure can be divided in 176 five steps: 178 1.EAP identity exchange (i.e. exchange of EAP Request Identity and 179 EAP Response Identity messages); 181 2.PEAPv2 Phase 1: MN and AAAH establish a TLS tunnel to protect 182 subsequent authentication data. This phase is completely 183 conformant to [2]; 185 3.PEAPv2 Phase 2: MN and AAAH negotiate an EAP method (e.g. EAP-MD5, 186 EAP-SIM, EAP-AKA) and undertake the authentication phase. Then, 187 within the TLS tunnel, MN and AAAH exchange a sequence of EAP-TLVs 188 to authorize and configure Mobile IPv6. During this phase, AAAH 189 selects a suitable Home Agent for the MN and exchanges 190 authorization and configuration data with it using a new Diameter 191 Application. At the end of this phase, the MN knows its own Home 192 Address, the address of the correspondent Home Agent and the 193 cryptographic material (e.g. pre-shared key) needed to set-up an 194 IPsec security association with IKE; 196 4.EAP session termination (EAP Success/Failure); 198 5.set-up of IPsec Security Association and MIPv6 registration: at 199 the end of the EAP communication, the MN gains network access and 200 acquires a valid Care-of Address within the visited subnet (e.g. 201 stateless autoconfiguration); then, using the cryptographic 202 material collected in PEAPv2 phase 2, it performs an IKE exchange 203 to establish the IPsec Security Association with the HA. Finally, 204 the MN performs MIPv6 registration, sending a Binding Update 205 (protected with IPsec) to the HA. 207 EAP over 208 IEEE 802.1x EAP over Diameter Diameter 209 (or PANA) (or RADIUS) AAAH HA Application 210 MN +----------+ AP +-----------------+ Server +-----------------+ HA 212 1) <--Req. Id.--- 213 --Identity---> --Diameter EAP Req.--> 214 /----------------------------------\ 215 2) / PEAPv2 Phase 1: \ 216 \ set-up of TLS tunnel / 217 \----------------------------------/ 218 /----------------------------------\ +-+ /------------------\ +-+ 219 3) / PEAPv2 Phase 2: authentication \| |/ Home Address \| | 220 \ and Mobile IPv6 negotiation /| |\ Selection /| | 221 \----------------------------------/ +-+ \------------------/ +-+ 222 Home Agent DAD 223 Selection 225 4) <-----EAP----- <-----Diameter EAP---- 226 Success/Failure Answer (Success/Failure 227 and authorization AVPs) 229 /-----------------------------------------------------------\ 230 5) / Set-up Security Association MN-HA and \ 231 \ Mobile IPv6 registration (BU, BA) / 232 \-----------------------------------------------------------/ 234 Figure 2 - Overview of Mobile IPv6 bootstrap procedure 236 This draft also defines the procedures to handle re-authentication 237 events and to manage the termination of the Mobile IPv6 session. 239 In summary, the proposed architecture has the following advantages: 241 - allows the operator to maintain a centralized management (on the 242 AAA server) of the user profiles and the authentication, 243 authorization and accounting procedures for any type of service, 244 including Mobile IPv6; 246 - improves the reliability and performance of the Mobile IPv6 247 protocol, in that the HA to be dynamically assigned to the MN can 248 be freely chosen among those that are closest to the user's point 249 of attachment, thus optimizing network usage and reducing the 250 transfer delay for data traffic in bi-directional tunneling; 252 - can be deployed, or extended with new features, without having to 253 update the access equipment and the AAA protocols in use. Only 254 minor changes in the AAA servers, the Home Agents and the mobile 255 terminals are required, in that the AAA client does not play any 256 active role in MIPv6 negotiation (i.e. it is a pass-through for 257 EAP signaling). This reduces the deployment costs and makes the 258 solution easy to use even when a Mobile Node is roaming with a 259 provider different from its own; 261 - allows the usage of any AAA protocol supporting the transport of 262 EAP messages for the communication between the AAA client and 263 server (i.e. not just Diameter, but also RADIUS). This 264 significantly simplifies the deployment of the arrangement 265 described herein in existing communication networks, where support 266 for Diameter protocol in access equipment is not so extensive. 268 Conversely, the drawback of the solution is the high number of RTTs 269 needed for the completion of the entire procedure. This limitation is 270 mainly due to the choice of relaying on a tunneled EAP method (such 271 as PEAPv2) for exchanging protected signaling related to MIPv6 during 272 the authentication phase. Nevertheless, it should be noted that the 273 full procedure can be undertaken by the MN only during its initial 274 bootstrap, and therefore the performance requirements are not so 275 strict. 277 3. Detailed Description of the Protocol 279 This section details all the procedures and message exchanges that 280 can be used by the network operator to explicitly authorize the 281 activation of Mobile IPv6 support for a specific user as well as 282 enable dynamic negotiation of MIPv6 protocol parameters (e.g. Home 283 Address, Home Agent Address). 285 For the sake of simplicity, protocol description is carried out 286 assuming that the access network is a Wireless LAN IEEE 802.11 where 287 user authentication is performed at Layer 2 through IEEE 802.1x and 288 EAP. However, the same approach can be deployed in any other network 289 using EAP for access control. 291 3.1 Mobile Node bootstrap 293 In a WLAN where IEEE 802.1x and EAP are used for access control, when 294 the MN enters the network it immediately receives an EAP Request 295 Identity message. This message is used to start the EAP 296 communication. The MN replies sending its identity, in the form of a 297 NAI (Network Access Identifier), within an EAP Response Identity 298 message, that is received by a local attendant (i.e. the Access Point 299 in the case of a WLAN) and forwarded to AAAH using the Diameter EAP 300 Application (or the RADIUS EAP extensions). Then the AAAH server 301 selects an EAP method (e.g. based on the user service profile) and 302 proposes it to the MN in subsequent EAP messages. In order to use the 303 MIPv6 negotiation procedure defined in this document, the EAP method 304 chosen by the AAAH server must be PEAPv2 or another tunneled EAP 305 method supporting the transport of optional information fields. 307 After this initial handshake, MN and AAAH establish a TLS tunnel 308 exchanging PEAPv2 phase 1 messages. The procedure is the same 309 specified in [2] and the Access Point acts as a simple pass-through 310 for all the signaling transferred, on an end-to-end basis, between 311 the MN and the AAA server. 313 As soon as the TLS tunnel is established, the actual authentication 314 phase takes place and all messages exchanged between MN and AAAH are 315 encrypted through the TLS Security Association. The authentication 316 can be based on any EAP method (e.g. EAP-MD5, EAP-SIM, EAP-AKA): the 317 choice can be done based on the desired security level and keeping in 318 mind that the EAP method affects the number of RTTs needed to 319 accomplish the authentication. 321 The authentication procedure performed within the TLS tunnel (i.e. 322 inner authentication) can be divided in three main steps: 324 1.Identity Exchange: exchange of EAP Identity Request/Reply 325 messages; 327 2.Authentication Algorithm: this is the real authentication 328 procedure. The number of round trips (RTTs) needed to complete 329 this phase depends on the EAP method chosen to perform inner 330 authentication; 331 3.Authentication Result: in the last round trip, AAAH sends to the 332 MN the result of the authentication procedure (success/failure) 333 and the MN confirms the reception of this notification. 335 PEAPv2 phase 2 messages exchanged within the TLS tunnel are conveyed 336 in EAP-TLVs, according to the latest version of PEAPv2 specification. 338 As soon as the authentication phase is completed (i.e. MN has 339 received an EAP Response message containing an Intermediate-Result- 340 TLV), the procedure for Mobile IPv6 authorization and parameter 341 negotiation takes place. This is achieved exploiting the TLS tunnel 342 to exchange a sequence of EAP messages containing a new TLV, called 343 MIPv6-Authorization-TLV (see section 6.1), that is a very generic TLV 344 containing other, more specific, TLVs. 346 AAAH starts the MIPv6 negotiation phase sending to the MN a MIPv6- 347 Authorization-TLV including the following TLVs: 349 - Service-Status-TLV: used to communicate to the MN whether the 350 Mobile IPv6 service is actually available, or unavailable, in the 351 visited location; this might depend on characteristics of the 352 visited domain, on the user service profile or on other 353 administrative rules (e.g. service accountability); 355 - Service-Options-TLV (optional): used to specify other service 356 options the MN can ask for (possibility to register multiple CoAs, 357 allocation of a HA in the visited domain, etc.). See Appendix A 358 for an example. 360 MN replies to this first message confirming its intention to start 361 Mobile IPv6 and, optionally, providing a set of hints on the desired 362 service capabilities; this is achieved delivering a MIPv6- 363 Authorization-TLV including the following TLVs: 365 - Service-Selection-TLV: used by the MN to specify if it is willing 366 to activate Mobile IPv6 protocol operation; 368 - Service-Options-TLV (optional): used by the MN to communicate 369 which service options, among those previously advertised by AAAH, 370 it would like make use of; 372 - Home-Agent-Address-TLV (optional): used by the MN to suggest a 373 preferred Home Agent (e.g. a HA with whom the MN has a pre- 374 configured Security Association). The AAAH server treats this 375 indication just as a hint, which means that, for administrative 376 reasons, the MN may be assigned a Home Agent different from the 377 one previously requested; 378 - Home-Address-TLV (optional): used by the MN to suggest a preferred 379 Home Address (e.g. an address pre-configured on one of its network 380 interfaces); like the previous TLV, this indication is considered 381 only as a hint by the AAAH; 383 - Interface-Identifier-TLV (optional): through this TLV, the MN can 384 suggest a preferred Interface Identifier (selected according to 385 [5] or following other criteria) to be used by the AAA 386 infrastructure to build the Home Address starting from the 387 selected home prefix. Also in this case, this information, if 388 present, is treated as a pure hint by AAAH. 390 The whole message exchange is depicted in Figure 3. For the sake of 391 simplicity, the diagram shows only the content of the EAP-TLVs 392 exchanged within the TLS tunnel in place between the MN and AAAH 393 server. 395 PEAPv2 Diameter 396 TLS Tunnel AAAH HA Application 397 MN +----------------------------+ Server +---------------------+ HA 399 <--------------------- 400 EAP-TLV(MIPv6-Authorization-TLV( 401 Service-Status, [Service-Options])) 403 -----------------------> 404 EAP-TLV(MIPv6-Authorization-TLV( 405 Service-Selection, [Service-Options], 406 [Home-Agent-Address], [Home-Address], 407 [Interface-Identifier])) 409 Figure 3 - Mobile IPv6 authorization: initial handshake 411 If in the Service-Selection-TLV the MN has chosen not to make use of 412 Mobile IPv6, AAAH immediately terminates the EAP communication 413 skipping any further MIPv6 negotiation. 415 Otherwise, if the MN has confirmed its willingness to start MIPv6 416 service, AAAH selects a suitable Home Agent through a Home Agent 417 Selection Algorithm. Possible parameters to be taken into account by 418 this algorithm include: current load of available HAs, location of 419 the MN and, eventually, the preferences provided by the MN itself in 420 the previous message exchange (i.e. Service-Options-TLV, Home-Agent- 421 Address-TLV, Home-Address-TLV). However, the detailed definition of a 422 Home Agent Selection Algorithm is out of the scope of this document. 424 As soon as a suitable HA has been identified, AAAH interacts with it 425 to dynamically configure all the state needed to enable subsequent 426 MIPv6 protocol operations. The communication between AAAH and HA is 427 achieved through a new Diameter Application defined in this document, 428 that is called Diameter Home Agent Application and is similar to the 429 one specified in [6]. 431 AAAH starts the handshake sending to the designated HA a Diameter 432 Home Address Request (HAR) message containing the following AVPs: 434 - User-Name-AVP: specifies the MN's identity, that is the NAI 435 provided by the user while executing the inner EAP method; 437 - Home-Address-AVP or Interface-Identifier-AVP (optional): specify 438 the Home Address, or the Interface Identifier, provided by the MN 439 in the correspondent TLVs (i.e. Home-Address-TLV and Interface- 440 Identifier-TLV); 442 - HA-Features-AVP (optional): lists the additional features that the 443 HA is required to provide to the mobile node (e.g. support for the 444 registration of multiple CoAs). The content of this AVP is set by 445 the AAAH server based on the negotiation undertaken with the MN 446 through the Service-Options-TLV. 448 When the HA receives the message, it picks up a Home Address for the 449 MN, generating an Interface Identifier based on [5] or using the 450 hints included in the Home-Address-AVP (or in the Interface- 451 Identifier-AVP). Then the HA undertakes the Duplicate Address 452 Detection (DAD) procedure to verify the uniqueness of the selected 453 Home Address. 455 If DAD fails (i.e. an address duplication is detected on the home 456 link), the HA selects another Home Address for the MN and repeats the 457 whole DAD procedure. If this operation fails for three times in a 458 row, the Home Agent sends to the AAAH a Diameter Home Address Answer 459 (HAA) message with Result-Code equal to FAILURE. At this stage, AAAH 460 can try to assign another HA or close the negotiation sending to the 461 MN a Service-Status-TLV stating that the Mobile IPv6 service is not 462 active and not available (see section 6.1). 464 If DAD is completed successfully, the HA uses proxy Neighbor 465 Discovery to defend the Home Address on the home link but does not 466 begin to intercept data packets addressed to it until a valid Binding 467 Update (BU) is received from the MN (see section 4). Then the HA 468 replies to AAAH delivering a Diameter Home Address Answer (HAA) 469 containing the following AVPs: 471 - User-Name-AVP: as usual it includes the NAI of the MN; 473 - Home-Address-AVP: specifies the Home Address that the Home Agent 474 has allocated to the MN. 476 Figure 4 depicts the exchange of HAR and HAA messages in the case the 477 Home Address selection procedure carried out by the HA terminates 478 without errors. 480 PEAPv2 Diameter 481 TLS Tunnel AAAH HA Application 482 MN +----------------------------+ Server +---------------------+ HA 484 +-+ 485 |O| 486 +-+ 487 Home Agent 488 Selection 490 ----------------------> 491 Home-Address-Request( 492 User-Name, [HA-Features], 493 [Home-Address], [Interface-ID]) 495 <----------------------- 496 Home-Address-Answer( 497 User-Name, Home-Address) 499 Figure 4 - Mobile IPv6 authorization: Home Address selection 501 AAAH also acts as Key Distribution Center, delivering to MN and HA 502 the cryptographic data needed to bootstrap the IPsec Security 503 Association for protecting subsequent Mobile IPv6 signaling. For this 504 reason, after the reception of the designated Home Address from the 505 HA, AAAH continues the handshake sending to the HA a Diameter Home 506 Agent Configuration Request (HACR) message containing the following 507 AVPs: 509 - User-Name-AVP: the NAI of the MN; 511 - Authorization-Lifetime-AVP: it is the authorization lifetime (in 512 seconds) of the Mobile IPv6 service granted to the MN; 514 - IKE-Bootstrap-Information-AVP: this AVP specifies the peer 515 authentication method to be used for IKE phase 1 (Pre-Shared key, 516 certificates, etc.) and the related parameters (e.g. value of the 517 pre-shared key and its lifetime). This is all the information the 518 HA needs to negotiate the IPsec Security Association with the MN. 519 This draft specifies in detail only the approach based on a Pre- 520 shared Key (PSK); 521 - Policy-AVP (optional): contains some filtering rules (e.g. access 522 lists) to be enforced by the HA on the traffic the MN transmits 523 and/or receives in bi-directional tunneling. 525 Once the HA has stored these data in its Service Authorization Cache 526 (see section 4.1), it sends to AAAH a Diameter Home Agent 527 Configuration Answer (HACA) containing a Result-Code-AVP used to 528 confirm the success (or failure) of the procedure (see Figure 5). 530 PEAPv2 Diameter 531 TLS Tunnel AAA HA Application 532 MN +---------------------------+ Server +----------------------+ HA 534 +-+ 535 |O| 536 +-+ 537 IKE Configuration 538 Selection 540 -----------------------> 541 HA-Configuration-Request( 542 User-Name, Auth. Lifetime, 543 IKE-Bootstrap-Info, [Policy]) 545 <----------------------- 546 HA-Configuration-Answer( 547 User-Name, Result-Code) 549 Figure 5 - Mobile IPv6 authorization: HA configuration 551 At this stage, the HA is ready to accept future MIPv6 registrations 552 coming from the MN. Therefore, AAAH can restart the EAP session with 553 the MN communicating to it all the MIPv6 configuration data it is 554 waiting for. This is achieved delivering to the MN an EAP Request 555 containing a MIPv6-Authorization-TLV including the following TLVs: 556 Home-Address-TLV (i.e. the home address), Home-Agent-Address-TLV 557 (i.e. the address of the HA), IKE-Bootstrap-Information-TLV (i.e. the 558 information needed to bootstrap the IKE session with the HA). 560 As soon as it receives this message, the MN stores all the 561 configuration data and sends back an EAP Reply containing a 562 Negotiation-Result-TLV, stating whether it accepts, or refuses, the 563 proposed configuration (see Figure 6). If the MN refuses the 564 configuration, AAAH should immediately release the resources 565 previously allocated on the HA. To complete this task, AAAH sends a 566 Diameter Abort Session Request (ASR) message to the Home Agent (see 567 paragraph 3.3). 569 PEAPv2 Diameter 570 TLS Tunnel AAAH HA Application 571 MN +----------------------------+ Server +---------------------+ HA 573 <--------------------- 574 EAP-TLV(Result-TLV, 575 Crypto-Binding-TLV, 576 MIPv6-Authorization-TLV( 577 Home-Address, HA-Address, 578 IKE-Bootstrap-Info)) 580 -----------------------> 581 EAP-TLV(Result-TLV, 582 Crypto-Binding-TLV, 583 MIPv6-Authorization-TLV( 584 Negotiation-Result)) 586 Figure 6 - Mobile IPv6 authorization: MN configuration 588 To terminate the EAP session, AAAH sends to the Access Point a 589 Diameter EAP Answer message with Result-Code equal to SUCCESS and, 590 optionally, other authorization AVPs containing some filtering rules 591 to be enforced on MN's traffic (see Figure 7). 593 EAP Over EAP over Diameter 594 802.1x Diameter AAA HA Application 595 MN +---------+ AP +------------+ Server +----------------------+ HA 597 <------------------- 598 Diameter-EAP-Answer( 599 Result-Code-AVP(Success), 600 EAP-Payload-AVP(EAP-Success), 601 [Authorization AVPs]) 602 +-+ 603 |O| Enforcement of 604 +-+ authorization rules 606 <------------- 607 EAP-Success 609 Figure 7 - Termination of the EAP session 611 After the completion of the EAP session, MN holds all data needed to 612 perform Mobile IPv6 registrations: the MN knows its Home Address, the 613 address of the correspondent Home Agent and all cryptographic 614 material needed to establish the IPsec security association with it; 615 furthermore, since it has been successfully authenticated, the MN is 616 receiving Router Advertisements on the visited subnet and can build 617 its Care-of Address through IPv6 stateless autoconfiguration. 619 The first operation carried out by the MN after the acquisition of 620 the Care-of Address is the establishment of the IPsec Security 621 Association with the HA, that is mandated by [1] to protect MIPv6 622 location update signaling. Set-up of the IPsec SA can be accomplished 623 following the procedure detailed in [7]. In this regard, it is 624 important to note that: 626 - if the mutual authentication in IKE Phase 1 is based on a Pre- 627 Shared Key (PSK), Aggressive Mode must be used. This is because 628 Aggressive Mode is the only way to use PSK authentication with a 629 NAI as peer identifier [8]. Indeed, the NAI of the MN is the only 630 identity information stored in the Service Authorization Cache of 631 the HA; 633 - in IKE phase 1 messages, the source address used by the MN has to 634 be the Care-of Address, as described in [7]; the Home Address is 635 used only in IKE phase 2; 637 - in IKE phase 2 (Quick Mode), while still using the CoA as source 638 address of IKE messages, the MN has to use the Home Address as its 639 peer identifier, so that the HA can correctly set the MN entries 640 in its Security Policy Database (SPD) and in the Security 641 Association Database (SAD). 643 As soon as the IPsec Security Association is established, MN can send 644 a Binding Update to the HA, thus starting up Mobile IPv6 service 645 (Figure 8). 647 AAA 648 MN +--------+ AP +--------------+ Server +---------------------+ HA 650 /------------------------------------------------------------\ 651 / IKE Phase 1 \ 652 \ Aggressive Mode (2 RTT) / 653 \------------------------------------------------------------/ 655 /------------------------------------------------------------\ 656 / IKE Phase 2 \ 657 \ Quick Mode (1 + 1/2 RTT) / 658 \------------------------------------------------------------/ 660 --------------------------------------------------> 661 MIPv6 Binding Update 663 <-------------------------------------------------- 664 MIPv6 Binding Acknowledge 666 Figure 8 - IKE Negotiation and MIPv6 Registration 667 Considering the usage of an inner EAP method involving 2 round trips 668 (e.g. EAP-AKA), the bootstrap procedure described in the foregoing 669 requires a total of 13.5 round trips (RTTs) to be completed: 9 RTTs 670 for authentication and Mobile IPv6 negotiation, 3.5 RTTs for setting 671 up the IPsec SA (i.e. IKE) and 1 RTT for MIPv6 registration (i.e. BU, 672 BA). However, since the whole procedure may be performed only at the 673 MN bootstrap (e.g. when the terminal is switched on), the time 674 requirements are not critical. 676 Nonetheless, a number of optimization steps can be introduced in 677 order to make the whole procedure faster. The PEAPv2 protocol 678 provides for several tasks to be performed simultaneously by 679 conveying the correspondent message exchanges in different TLV types, 680 all delivered through the TLS tunnel in place between MN and AAAH. 681 Exploiting this feature, the negotiation procedure for the MIPv6 682 service can be performed in partial or complete superposition with 683 the authentication procedure. This optimization leads to saving 2 684 round trips. Additionally, the time for the HA to complete the DAD 685 procedure may be partially or totally absorbed within the 686 authentication procedure. 688 3.2 Management of reauthentication events 690 At the expiration of AAA session time-outs or after a change in the 691 point of attachment to the network (involving or not involving an IP 692 handoff), a re-authentication procedure is performed leading to the 693 user identity to be checked again along with its right to continue 694 exploitation of network resources. To that purpose the AAAH server 695 may repeat a full authentication or, alternatively, decide to use 696 optimizations in order to make the procedure faster. Once this phase 697 is completed the AAA server also undertakes the re-negotiation of the 698 Mobile IPv6 service, communicating with the MN through the TLS 699 tunnels established in PEAPv2 phase 1. The actual protocol behavior 700 and message exchange may vary depending on the service state of the 701 mobile node. 703 If the MIPv6 service is not currently active for the MN, AAAH behaves 704 exactly as in the bootstrap phase (see section 3.1) and proposes the 705 activation of the service from scratch as if the MN was performing 706 its first authentication within the visited network. 708 Instead, if the MIPv6 service is already active, AAAH informs the MN 709 about the current MIPv6 service status, including the respective 710 service options negotiated during the bootstrap phase. AAAH performs 711 this operation delivering a MIPv6-Authorization-TLV including the 712 Service-Status-TLV and the Service-Options-TLV. The mobile node may 713 respond in two different ways: 715 - by means of a Negotiation-Result-TLV with result code equal to 716 SUCCESS, to indicate that the service configuration is wished to 717 be maintained unchanged, 719 - or by means of a MIPv6-Authorization-TLV with the desired 720 modifications (including the eventual request to stop the MIPv6 721 service), to undertake the full or partial re-negotiation of the 722 MIPv6 service. 724 As a whole, the described re-authentication procedure takes 10 round 725 trips, assuming that the employed EAP method requires 2 round trips 726 (e.g. EAP-AKA) and the Mobile Node has undertaken an IP handoff 727 without asking for any change in the service configuration. 728 Consequently, 3.5 round trips are saved in comparison with the 729 bootstrap phase, in that the MN already shares an IPsec Security 730 Association with the HA and therefore does not need to repeat the IKE 731 negotiation. 733 The delay involved in completing the re-authentication procedure may 734 be reduced by resorting to the optimization steps already described 735 in the foregoing with reference to the bootstrap phase and, possibly, 736 by exploiting some additional optimizations supported by the PEAPv2 737 protocol: fast resume of the TLS tunnel and fast reconnect. 739 3.3 Session Termination 741 Session termination may be triggered by the AAA server or the mobile 742 node. The result is normally the disconnection of the user from the 743 visited network, and, consequently, the release of Mobile IPv6 744 service and related resources (Home Agent, Home Address, etc.). 746 The AAA server may decide to close the session at any moment, for 747 instance due to credit exhaustion. In general, to interrupt the 748 service, the AAA server delivers to the correspondent AAA client a 749 Diameter Abort Session Request (ASR) message; the AAA client 750 disconnects the user, releases the resources previously allocated to 751 it and confirms the session termination through a Diameter Abort 752 Session Answer (ASA) message. If a plurality of clients are involved 753 in the service provision, the ASR message is sent to all of them. In 754 the specific case of the Mobile IPv6 service, the two Diameter 755 clients involved are the HA and the equipment that is providing 756 access to the network (i.e. the Access Point in case of a Wireless 757 LAN), therefore both receive an ASR message from AAAH (see Figure 9) 758 and enforce immediate user disconnection. 760 Diameter 761 AAA HA Application 762 MN +--------+ AP +-------------+ Server +----------------------+ HA 764 <------------------- 765 Diameter-Abort-Session-Request( 766 User-Name-AVP) 767 --------------------> 768 Diameter-Abort-Session-Request( 769 User-Name-AVP) 770 ------------------> 771 Diameter-Abort-Session-Answer( 772 Result-Code-AVP) 773 <------------------------ 774 Diameter-Abort-Session-Answer( 775 Result-Code-AVP) 777 Figure 9 - MIPv6 service termination triggered by AAAH 779 In the case the MN wishes to disconnect, it sends an EAPOL-Logoff 780 message toward the Access Point which in turn communicates the end of 781 the session to the AAA server via the Diameter Session Termination 782 Request (STR) message, while simultaneously releasing the resources 783 involved. At the reception of the STR message, the AAA server 784 releases the resources allocated on the HA exchanging Abort Session 785 Request and Answer messages with it, while sending a corresponding 786 Diameter Session Termination Answer message toward the AP. 788 The AAA server may possibly decide to adopt different policies for 789 releasing the resources (e.g. depending the user service profile). 790 For instance, the AAA server may decide not to release the resources 791 on the HA in order to allow the MN to exploit the Mobile IPv6 service 792 even when it moves to network for which no roaming agreements exist 793 (e.g. a corporate network or a network providing free and cost-free 794 access). In that case, the MN can continue to use the IPsec SA 795 previously negotiated with the HA and respective authorization is 796 managed by means of the MIPv6 Authorization Lifetime (see Diameter 797 HACR message). Once this lifetime expires (but it may even be 798 infinite), the HA should send a Diameter Authorization Refresh 799 Request message to the AAAH server asking for a confirmation of the 800 authorization (see Figure 10). 802 Diameter 803 AAA HA Application 804 MN +--------+ AP +-------------+ Server +----------------------+ HA 806 +-+ 807 |O| 808 +-+ 809 Authorization 810 Lifetime Expiration 812 <------------------- 813 Diameter-Authorization- 814 Refresh-Request(User- 815 Name-AVP) 817 --------------------> 818 Diameter-Authorization- 819 Refresh-Answer(User-Name-AVP, 820 Result-Code-AVP, 821 [Authorization-Lifetime-AVP]) 823 Figure 10 - Diameter Authorization Refresh Request/Answer 825 In some circumstances, it might be desirable for the mobile node to 826 terminate the MIPv6 service only (and stop being charged for that), 827 while maintaining uninterrupted access to the visited network. 828 Relaying on the architecture described in the previous sections, this 829 result can be achieved in two different ways: 831 - the MN can wait till the next re-authentication event (usually 832 triggered by the network) and perform the re-negotiation of the 833 whole MIPv6 protocol operation (see section 3.2), 835 - or the MN can decide to stop sending Binding Updates to the HA, 836 causing the expiration of the correspondent entry in the Binding 837 Cache. This is interpreted by the HA as the MN's willingness to 838 stop using the Mobile IPv6 protocol. Therefore, the HA, behaving 839 similarly to a standard Network Access Server (NAS), sends a 840 Diameter Session Termination Request to the AAA server and, after 841 the reception of the correspondent Session Termination Answer, 842 releases all the resources previously allocated to the MN (i.e. 843 the Home Address and the entry in its Service Authorization 844 Cache). 846 4. Home Agent considerations 848 This section details some specific features and data structures that 849 have to be supported by the Home Agent to allow dynamic negotiation 850 of Mobile IPv6 protocol parameters during mobile node network 851 attachment. 853 4.1 Service Authorization Cache (SAC) 855 The Home Agent is required to store some authorization data for each 856 of the MNs it is serving. A new data structure, called Service 857 Authorization Cache (SAC), is used for this purpose. Each entry in 858 the SAC should contain at least the following fields: 860 - NAI of the user: it is derived from the User-Name-AVP included by 861 AAAH in all the Diameter messages addressed to the HA; 863 - Home Address: it is the Home Address (checked against DAD) that 864 the HA has dynamically assigned to the MN during the Mobile IPv6 865 bootstrap phase; 867 - Authorization Lifetime: it is the authorization lifetime of the 868 Mobile IPv6 service granted to the MN. AAAH selects this lifetime 869 according to administrative rules and specifies it in the 870 Authorization-Lifetime-AVP. Before the expiration of this 871 lifetime, the HA may send a Diameter Authorization Refresh Request 872 (ARR) message to AAAH asking for an extension (i.e. renewal) of 873 the authorization; 875 - Authentication Mode: it is the authentication mode to be used in 876 IKE Phase 1 for setting up the IPsec SA with the MN. This draft 877 specifies in detail only the approach based on a Pre-shared Key 878 (PSK); 880 - Cryptographic Data: this field includes all the information to be 881 used for IKE bootstrap. The actual content of this record depends 882 on the Authentication Mode chosen for IKE Phase 1: if Pre-shared 883 Key is used for this purpose, this field includes the PSK value 884 and its lifetime. 886 4.2 Management of Binding Cache entries 888 The selection of the Home Address to be assigned to the MN at the end 889 of the MIPv6 bootstrap phase is performed by the designated Home 890 Agent at the reception of the Diameter Home Address Request (HAR) 891 message from the AAAH server. Immediately after the completion of 892 this procedure, the HA is required to start defending the Home 893 Address (i.e. proxy Neighbor Discovery), even if it has not yet 894 received any Binding Update from the MN. This behavior is not 895 completely conformant with the Mobile IPv6 specification and has to 896 be treated carefully to avoid protocol failures on the HA. In 897 particular, the following anomaly might happen: 899 - at the end of the MIPv6 authorization and negotiation process 900 (i.e. the MN has completed the EAP communication and has been 901 explicitly authorized to use MIPv6 from its current point of 902 attachment), the MN sends a Binding Update (BU) message to 903 register its Care-of Address on the HA; 905 - the Home Agent receives the BU from the MN and, following the 906 MIPv6 protocol standard, checks the Home Address included in it 907 against DAD. Since the HA is already defending that Home Address, 908 DAD might happen to fail, blocking Mobile IPv6 functionality on 909 the MN. 911 To avoid this problem, when the HA starts defending the Home Address 912 allocated to the MN (i.e. immediately before replying to AAAH with 913 the Diameter Home Address Answer message), it should also register it 914 in its binding cache, creating a new entry where the Care-of Address, 915 that is still unknown, is initially set to unspecified (::) and the 916 correspondent lifetime is set to the MIPv6 authorization lifetime. In 917 this way, when the HA receives the first Binding Update from the MN, 918 the message is treated as an update of an existing entry in the 919 Binding Cache and therefore DAD is not performed. 921 In order for this procedure to work properly, the MN has to send a BU 922 to the HA as soon as it is granted IPv6 access to the visited subnet 923 (i.e. at the end of EAP authentication). If the visited subnet 924 happens to be on the home link, the MN should send to the HA a BU 925 with binding lifetime equal to 0, to make sure it cleans up the dummy 926 entry in its binding cache and stops defending the home address. 928 5. Protocol Applicability in Cellular Networks 930 Using the Mobile IPv6 protocol and the services offered thereby may 931 be desirable particularly to handle mobile node movements across a 932 multi-access environment, involving both WLANs and 3GPP radio 933 networks (i.e. vertical handoff). This scenario, in fact, is becoming 934 increasingly popular, due to the massive deployment of WLAN hot-spots 935 in public indoor areas like airports and hotels. 937 In cellular networks (e.g. GPRS, UMTS), access control and IP address 938 assignment are managed relaying on protocols that are specific of 939 cellular infrastructures (for instance, SS7/MAP), and therefore do 940 not natively support the use of EAP. For this reason, in such 941 environments the Mobile IPv6 authorization and configuration 942 procedure described in the previous sections can not be employed as 943 is, but must be properly adapted. 945 The proposed solution is based on the assumption that the MN performs 946 Mobile IPv6 service negotiation interacting with a AAA server 947 supporting Diameter, which remains logically unchanged regardless of 948 the access technology being used (i.e. WLAN or cellular). 949 Additionally, this AAA server must support a communication interface 950 towards the authentication center of the cellular operator (i.e. 951 HLR/AuC), but the details about this interaction are outside the 952 scope of this document. 954 When the MN enters a GPRS or UMTS data network, based on layer 2 955 signaling procedures specific of cellular environments, it is 956 assigned an IP address (v4 or v6) by activating a so called PDP 957 Context. This corresponds to establishing a direct layer 3 958 communication channel between the MN and the GGSN (GPRS Gateway 959 Support Node), that is basically the first router on the path towards 960 any external IP cloud (e.g. the Internet). 962 At this stage, to perform MIPv6 negotiation as described in the 963 previous sections, it is necessary to establish an additional 964 communication channel based on EAP over the existing IP transport 965 (i.e. over the PDP Context). This can be achieved activating a PANA 966 [9] session between the MN and the GGSN, used for the sole purpose of 967 authorizing and configuring (or re-negotiating, if it was already 968 active) the Mobile IPv6 service. 970 This procedure consists of the exchange of MIPv6 TLVs transported 971 directly over EAP (i.e. exchange of EAP messages with EAP-Type equal 972 to EAP-TLV). In this case, there is no need to protect this signaling 973 establishing a TLS tunnel through PEAP, because there is already a 974 secure channel in place between MN and GGSN, provided by the PDP 975 Context. Moreover, it is not necessary to carry out any further 976 authentication procedures, because the user has already been 977 authenticated via HLR/AuC and SS7/MAP. 979 The whole procedure includes the following steps (Figure 11): 981 - GGSN and MN establish a PANA session (PANA-Start-Request/Answer). 982 The communication is triggered by the GGSN message as soon as the 983 PDP Context activation is complete; 985 - GGSN sends to the AAA server a Diameter EAP Request message 986 containing the user identifier (NAI) and an empty EAP packet, 987 indicating the need of starting an EAP exchange. The NAI is 988 constructed directly by the GGSN, that is a trusted node, using 989 the MN credentials collected during the PDP Context activation. 991 Since these credentials (i.e. essentially the data contained in 992 the SIM/USIM) have already been verified using protocols specific 993 of cellular networks (e.g. SS7/MAP), there is no need to undertake 994 a new authentication phase; 996 - at the reception of the Diameter EAP Request message from the 997 GGSN, the AAA server understands that the MN is already 998 authenticated (e.g. interacting with the HLR/AuC) and starts 999 directly the Mobile IPv6 negotiation phase, sending EAP messages 1000 containing solely the MIPv6-Authorization-TLV. The negotiation 1001 goes on as already described in section 3.1 for WLAN access. 1003 - if the negotiation terminates successfully, the AAA server sends 1004 to the GGSN an EAP Success message conveyed within a Diameter EAP 1005 Answer; the GGSN forwards this notification to the MN through a 1006 PANA-Bind-Request message. Finally, MN closes the exchange 1007 replying with a PANA-Bind-Answer. 1009 At any time, the MN may request the termination of the PANA session, 1010 and consequently the release of the MIPv6 service, by means of a 1011 PANA-Termination-Request message sent to the GGSN node. Conversely, 1012 the AAA server may discontinue the delivery of the service sending a 1013 Diameter Abort Session Request message to the Home Agent. 1015 The main advantage of this procedure lies in the possibility of re- 1016 using those messages and TLVs defined in section 3.1 even when the MN 1017 accesses a cellular network, or, in general, any IP network (wireless 1018 or wired) performing user authentication with methods other than EAP. 1019 Instead, the drawback is that the GGSN, or, in general, the first 1020 router on the outbound routing path, has to support a new feature 1021 (i.e. the PANA protocol) and the MIPv6 service negotiation is not 1022 carried out together with the user authentication, but as an 1023 additional procedure following the MN network attachment. 1025 MN +-------------------------+ GGSN +--------------------------+ AAA 1027 /-----PDP Context Act. ------\ 1028 \----------------------------/ 1030 <----------------- 1031 PANA-Start-Request 1032 ------------------> 1033 PANA-Start-Answer -----------------------> 1034 Diameter-EAP-Request( 1035 EAP-Payload-AVP(empty), 1036 User-Name-AVP) 1037 <--------------------------------- 1038 Diameter-EAP-Answer(EAP-Payload-AVP(EAP- 1039 Request/EAP-Type=EAP-TLV(MIPv6-Authorization-TLV 1040 (Service-Status,[Service-Options])))) 1041 <---------------------- 1042 PANA-Auth-Request(EAP-Request) 1043 --------------------------> 1044 PANA-Auth-Answer(EAP-Response/EAP-Type=EAP-TLV 1045 (MIPv6-Authorization-TLV(Service-Selection, 1046 [Service-Options]))) 1047 -------------------> 1048 Diameter-EAP-Request +-+ 1049 HA select. |O| 1050 and config. +-+ 1052 <--------------------------------- 1053 Diameter-EAP-Answer(EAP-Payload-AVP( 1054 EAP-Request/EAP-Type=EAP-TLV(MIPv6 1055 Authorization-TLV(Home-Address 1056 HA-Address,IKE-Bootstrap-Info)))) 1057 <----------------- 1058 PANA-Auth-Request( 1059 EAP-Request) 1060 ------------------> 1061 PANA-Auth-Answer(EAP-Response/EAP-Type= 1062 EAP-TLV(MIPv6-Authorization-TLV 1063 (Negotiation-Result))) -------------------> 1064 Diameter-EAP-Request 1065 <-------------------------- 1066 Diameter-EAP-Answer( 1067 EAP-Payload-AVP(EAP-Success)) 1068 <--------------------- 1069 PANA-Bind-Request(EAP-Success) 1070 ------------------> 1071 PANA-Bind-Answer 1073 Figure 11 - MIPv6 service authorization in 3GPP networks 1074 6. New Messages and Attributes 1076 6.1 New EAP-TLVs 1078 The general format of an EAP-TLV is depicted in Figure 12 [10]. 1080 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 |M|R| Type | Length | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | Value... 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 Figure 12 - Generic TLV format 1089 TLVs defined in this draft are: 1091 - MIPv6-Authorization-TLV. This is a generic TLV which carries all 1092 TLVs related to MIPv6 authorization and configuration. It is 1093 defined as follows: 1095 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 |M|R| Type | Length | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Value... 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 M 1104 0 - Non-mandatory TLV 1106 R 1108 Reserved, set to zero (0) 1110 Type 1112 TBD - MIPv6-Authorization 1114 Length 1116 The length of the Value field in octets 1118 Value 1120 This field carries the subsequent TLVs 1121 - Service-Status-TLV. This TLV is sent by the AAAH to inform the MN 1122 about the status of Mobile IPv6 service. It is defined as follows: 1124 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | Type=Service-Status | Length | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | Code | 1129 +-+-+-+-+-+-+-+-+ 1131 Type 1133 TBD - Service-Status 1135 Length 1137 1 1139 Code 1141 0 = MIPv6 service is not active and not available 1142 1 = MIPv6 service is not active but available 1143 2 = MIPv6 service is active but no more available 1144 3 = MIPv6 service is active and available 1146 - Service-Selection-TLV. This TLV is sent by the MN to inform the 1147 AAAH whether it accepts the AAAH proposal. 1149 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | Type=Service-Selection | Length | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | Code | 1154 +-+-+-+-+-+-+-+-+ 1156 Type 1158 TBD - Service-Selection 1160 Length 1162 1 1164 Code 1166 0 = MN accepts configuration options proposed by AAAH 1167 1 = activate MIPv6 service 1168 2 = re-negotiate MIPv6 service 1169 3 = deactivate MIPv6 service 1171 - Service-Options-TLV. So far only two service options are defined: 1172 the multiple registration option and the HA in visited network 1173 option. This TLV is defined as follows: 1175 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 | Type=Service-Options | Length | 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 |H|M| Reserved | 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 Type 1184 TBD - Service-Options 1186 Length 1188 2 1190 H 1192 1 - The MN is requesting a HA in the visited network 1194 M 1196 1 - The MN is requesting multiple registration functionalities 1198 Reserved 1200 14 bit reserved set to 0 1202 - Home-Agent-Address-TLV. It is defined as follows: 1204 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 | Type=HA-Address | Length | 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 | | 1209 | Home Agent Address | 1210 | | 1211 | | 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 Type 1215 TBD - Home-Agent-Address 1217 Length 1219 16 1221 Value 1223 Home Agent Address 1225 - Home-Address-TLV. It is defined as follows: 1227 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 | Type=Home-Address | Length | 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 | | 1232 | Home Address | 1233 | | 1234 | | 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 Type 1239 TBD - Home-Address 1241 Length 1243 16 1245 Value 1247 Home Address 1249 - IKE-Bootstrap-Information-TLV. This TLV carries data related to 1250 IKE bootstrap; the generic format is defined as follows: 1252 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 | Type=IKE-Bootstrap-Info | Length | 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | Auth. Type | IKE Phase 1 Mode | 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 | Authentication Information... 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 Type 1262 TBD - IKE-Bootstrap-Information 1264 Length 1266 Depending on Authentication Type 1268 Value 1270 Authentication Type 1272 The authentication method to be used in IKE Phase 1 1274 IKE Phase 1 Mode 1276 The mode to be used in IKE Phase 1 1278 Authentication Information 1280 This field contains cryptographic material to setup 1281 the security association. 1283 The figure below depicts the IKE-Bootstrap-Information-TLV when PSK 1284 is used as Authentication Type. 1286 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 | Type=IKE-Bootstrap-Info | Length | 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 | PSK | Aggressive Mode | 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 | Key Lifetime | 1293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1294 | Key Value... 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 Type 1299 TBD - IKE-Bootstrap-Information 1301 Length 1303 8 + Key length 1304 Value 1306 Authentication Type 1308 PSK 1310 IKE Phase 1 Mode 1312 Aggressive Mode 1314 Authentication Information 1316 Key Lifetime - the lifetime of the PSK 1318 Key Value - the value of the PSK 1320 - Negotiation-Result-TLV. It is defined as follows: 1322 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | Type=Result | Length | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | Result-Code | 1327 +-+-+-+-+-+-+-+-+ 1329 Type 1331 TBD - Result 1333 Length 1335 1 1337 Value 1339 0 - Success 1340 128 - Failure 1342 6.2 New Diameter messages and AVPs 1344 In this draft a new Diameter Application, called Home Agent Diameter 1345 Application, is proposed. The complete and detailed definition of the 1346 application is outside the scope of this document; even so, this 1347 section lists all new Diameter messages and AVPs introduced. 1349 The Diameter messages defined are: 1351 - Home Address Request. This message is sent by AAAH to the HA to 1352 request a Home Address; it includes these AVPs: 1353 o User-Name-AVP 1354 o Home-Address-AVP (optional) 1355 o Interface-Identifier-AVP (optional) 1356 o HA-Features-AVP (optional) 1358 - Home Address Answer. Through this message the Home Agent sends to 1359 AAAH the parameters it has reserved for a particular MN; it 1360 includes these AVPs: 1361 o User-Name-AVP 1362 o Home-Address-AVP 1364 - Home Agent Configuration Request. AAAH sends this message to the 1365 HA to give some information related to MIPv6 service activation; 1366 it includes these AVPs: 1367 o User-Name-AVP 1368 o Authorization-Lifetime-AVP 1369 o IKE-Bootstrap-Information-AVP 1370 o Policy-AVP (optional) 1372 - Home Agent Configuration Answer. Through this message the HA gives 1373 to AAAH the result of MIPv6 configuration procedure; it includes 1374 these AVPs: 1375 o User-Name-AVP 1376 o Result-Code-AVP 1378 - Authorization Refresh Request. The HA sends this message to AAAH 1379 when the Authorization Lifetime is going to elapse, requesting 1380 whether the user is still authorized to use MIPv6. It includes 1381 these AVPs: 1382 o User-Name-AVP 1384 - Authorization Refresh Answer. Through this message, AAAH specifies 1385 whether the MN is still authorized to use MIPv6. If the user is no 1386 longer authorized, the lifetime in Authorization-Lifetime-AVP is 1387 set to 0. It includes these AVPs: 1388 o User-Name-AVP 1389 o Result-Code-AVP 1390 o Authorization-Lifetime-AVP (optional) 1392 - Foreign Home Agent Request. AAAH sends this message to AAAF to 1393 request a Home Agent allocation. 1394 o User-Name-AVP 1395 o Home-Agent-Address-AVP (optional) 1396 o HA-Features-AVP (optional) 1397 o Home-Address-AVP (optional) 1398 o Interface-Identifier-AVP (optional) 1399 o Authorization-Lifetime-AVP (optional) 1400 o Policy-AVP (optional) 1402 - Foreign Home Agent Answer. AAAF sends this message to AAAH to give 1403 it the parameters related to MIPv6 activation. 1404 o User-Name-AVP 1405 o Home-Agent-Address-AVP 1406 o Home-Address-AVP 1407 o Authorization-Lifetime-AVP 1408 o IKE-Bootstrap-Information-AVP 1410 Diameter AVPs defined in this document are: 1412 - Home-Address-AVP. This AVP is of type IPAddress and the Data field 1413 contains a Home Address. 1415 - Home-Agent-Address-AVP. This AVP is of type IPAddress and the Data 1416 field contains the address of a Home Agent. 1418 - Interface-Identifier-AVP. This AVP is of type OctetString and the 1419 Data field contains an Interface Identifier that the MN can 1420 provide as a hint for Home Address selection on the HA. 1422 - IKE-Bootstrap-Information-AVP. This AVP is of type OctetString and 1423 contains data related to IKE bootstrap. The Data field has the 1424 same structure of the Value field defined for the IKE-Bootstrap- 1425 Information-TLV. 1427 - HA-Features-AVP. This AVP (type to be defined) carries information 1428 about specific features requested on the designated Home Agent 1429 (e.g. support for registration of multiple CoAs). 1431 - Policy-AVP. This AVP is of type IPFilterRule and defines a set of 1432 access lists to be enforced by the HA on the traffic generated by 1433 the mobile node. 1435 7. Open Issues 1437 Possible areas for future work are: 1439 - the usage of the AAA infrastructure, in place of IKE, to bootstrap 1440 the IPsec SA between the MN and the HA. This could be useful to 1441 reduce the number of round trips required for the completion of 1442 the MIPv6 negotiation procedure; 1444 - the exploitation of the EAP Key Management Framework [11] to allow 1445 the mobile node to derive the Pre-Shared Key used for IKE phase 1. 1447 This might improve the security of the architecture, in that it 1448 would not be necessary any more for the AAA server to send the PSK 1449 over the air (even if within a protected TLS tunnel); 1451 - the extension of the architecture to support the usage of digital 1452 certificates, in addition to PSK, for peer authentication in IKE 1453 phase 1; 1455 - a deeper analysis of the issues related to the interface between 1456 AAA server and HLR/AuC for the execution of the MIPv6 negotiation 1457 procedure in cellular networks. 1459 8. Security Considerations 1461 The Mobile IPv6 authorization and configuration exchange between the 1462 mobile node and the AAA server of the home domain is protected by a 1463 TLS tunnel established using PEAPv2. Therefore the level of security 1464 of this communication is the same of PEAPv2 message exchanges. 1466 The interaction between the AAA server and the designated Home Agent 1467 is based on Diameter, which means that it is protected using IPsec or 1468 TLS, as specified by the Diameter base protocol. 1470 Acknowledgments 1472 The authors would like to thank Simone Ruffino (of Telecom Italia 1473 Lab) for his feedback and suggestions. 1475 References 1477 [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 1478 IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July 1479 2003. 1481 [2] Palekar, A. et al., "Protected EAP Protocol (PEAP) Version 2", 1482 draft-josefsson-pppext-eap-tls-eap-07 (work in progress), 1483 October 2003. 1485 [3] Blunk, L. et al., "Extensible Authentication Protocol (EAP)", 1486 draft-ietf-eap-rfc2284bis-07 (work in progress), November 2003. 1488 [4] Funk, P., Blake-Wilson, S., "EAP Tunneled TLS Authentication 1489 Protocol (EAP-TTLS)", draft-ietf-pppext-eap-ttls-03 (work in 1490 progress), August 2003. 1492 [5] Narten, T., Draves, R., "Privacy Extensions for Stateless 1493 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 1495 [6] Faccin, S., Perkins, C., Le, F., Patil, B., "Diameter Mobile 1496 IPv6 Application", draft-le-aaa-diameter- mobileipv6-03 1497 (expired), April 2003. 1499 [7] Arkko, J., Devarapalli, V., Dupont, F., "Using IPsec to Protect 1500 Mobile IPv6 Signaling between Mobile Nodes and Home Agents", 1501 draft-ietf-mobileip-mipv6-ha-ipsec-06 (work in progress), June 1502 2003. 1504 [8] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 1505 2409, November 1998. 1507 [9] Forsberg, D. et al., "Protocol for Carrying Authentication for 1508 Network Access (PANA)", draft-ietf-pana-pana-02 (work in 1509 progress), October 2003. 1511 [10] Hiller, T., Palekar, A., Zorn, G., "A Container Type for the 1512 Extensible Authentication Protocol (EAP)", draft-hiller-eap- 1513 tlv-01, May 2003. 1515 [11] Aboba, B., Simon, D., Arkko, J., Levkowetz, H., " EAP Key 1516 Management Framework", draft-ietf-eap-keying-01.txt, October 1517 2003. 1519 Appendix A - Home Agent allocation in a foreign domain 1521 Whenever the mobile node is switched on inside a foreign domain (i.e. 1522 roaming scenario), it may be worthwhile assigning it a local Home 1523 Agent provided by the visited provider, rather than allocating a 1524 distant HA in the home domain. This may be useful to optimize network 1525 usage and reduce transfer delay for data traffic in bi-directional 1526 tunneling. 1528 The decision on the preferred position of the HA is taken by the AAAH 1529 server, either autonomously (e.g. based on the user profile or on 1530 other administrative policies) or negotiating with the MN through the 1531 Service-Options-TLV. In the latter case, the negotiation procedure is 1532 undertaken as follows: 1534 - in the first MIPv6-Authorization-TLV sent over the TLS tunnel 1535 established with PEAPv2, the AAAH server includes, together with 1536 the Service-Status-TLV, a Service-Options-TLV with the bit H set 1537 to 1, meaning that the allocation of a HA within the foreign 1538 domain is actually supported by the home provider; 1540 - if the MN wants to exploit this feature, it responds sending a 1541 MIPv6-Authorization-TLV including, in addition to the mandatory 1542 Service-Selection-TLV, a Service-Options-TLV with the bit H set to 1543 1, as a confirmation of its preference for the assignment of a 1544 local HA within the foreign domain. 1546 The rest of the procedure for bootstrapping MIPv6 protocol operation 1547 on the MN is carried out essentially as already described for the 1548 allocation of a HA inside the home domain (see section 3.1). The only 1549 major difference is that the AAAH server cannot perform HA selection 1550 and configuration by its own but has to interact with the AAA server 1551 of the foreign domain (i.e. AAAF). 1553 As a whole, the procedure undertaken by the AAAH server to obtain and 1554 configure a HA inside the foreign domain is based on the following 1555 steps (see Figure 13): 1557 - AAAH sends a Diameter Foreign Home Agent Request (FHAR) message to 1558 AAAF, indicating the user's NAI in the User-Name-AVP. Optionally, 1559 AAAH may insert other AVPs including the configuration hints 1560 eventually provided by the MN (HA-Address-AVP, Home-Address-AVP 1561 and Interface-Identifier-AVP), the additional features required on 1562 the HA (HA-Features-AVP), the desired authorization lifetime to be 1563 set on the designated HA (Authorization-Lifetime-AVP) and the 1564 filtering rules to be enforced on the traffic generated by the 1565 mobile node (Policy-AVP); 1566 - based on the information included in the request message, AAAF 1567 determines whether it can assign a HA within the local domain. In 1568 case the allocation is not possible (e.g. for administrative 1569 policies), or none of the available HAs actually supports the 1570 requested features (e.g. possibility to register multiple CoAs), 1571 AAAF replies with a Diameter Foreign Home Agent Answer (FHAA) 1572 message including a Result-Code-AVP set to FAILURE. In that case 1573 AAAH continues MIPv6 negotiation allocating a HA within the home 1574 domain. Instead, if AAAF can satisfy the request, it immediately 1575 determines a suitable Home Agent to be allocated to the MN using a 1576 Home Agent Selection Algorithm; 1578 - at this stage AAAF communicates with the selected HA using the 1579 same approach already described in section 3.1, based on the usage 1580 of Diameter Home Agent Request/Answer and Home Agent Configuration 1581 Request/Answer messages; 1583 - once the designated HA is properly configured (i.e. at the 1584 reception of the HACA message), AAAF delivers to AAAH a Diameter 1585 Foreign Home Agent Answer message including, in correspondent 1586 AVPs, all the information needed to activate the MIPv6 protocol 1587 operation on the MN (i.e. HA address, Home Address, Authorization 1588 Lifetime and IKE bootstrap information). 1590 Diameter Diameter 1591 AAAH HA Application AAAF HA Application 1592 Server +-----------------------+ Server +----------------------+ HA 1594 ------------------> 1595 Foreign-Home-Agent-Request(User-Name, 1596 [Home-Agent-Address],[Home-Address], 1597 [Interface-ID],[HA-Features], 1598 [Auth. Lifetime],[Policy]) 1599 +-+ 1600 |O| 1601 +-+ 1602 Home Agent 1603 Selection 1605 ----------------------> 1606 Home-Address-Request( 1607 User-Name, [HA-Features], 1608 [Home-Address], [Interface-ID]) 1610 <----------------------- 1611 Home-Address-Answer( 1612 User-Name, Home-Address, 1613 [IKE-Bootstrap-Info]) 1614 +-+ 1615 |O| 1616 +-+ 1617 IKE Configuration 1618 Selection 1620 -----------------------> 1621 HA-Configuration-Request( 1622 User-Name, Auth. Lifetime, 1623 IKE-Bootstrap-Info, [Policy]) 1625 <----------------------- 1626 HA-Configuration-Answer( 1627 User-Name, Result-Code) 1629 <------------------ 1630 Foreign-Home-Agent-Answer(User-Name, 1631 Home-Agent-Address,Home-Address, 1632 Auth. Lifetime,IKE-Bootstrap-Info, 1633 [Policy]) 1635 Figure 13 - Allocation of a Home Agent in the foreign domain 1636 Authors' Addresses 1638 Gerardo Giaretta 1639 Telecom Italia Lab 1640 via G. Reiss Romoli, 274 1641 10148 TORINO 1642 Italy 1643 Phone: +39 011 2286904 1644 Email: gerardo.giaretta@telecomitalia.it 1646 Ivano Guardini 1647 Telecom Italia Lab 1648 via G. Reiss Romoli, 274 1649 10148 TORINO 1650 Italy 1651 Phone: +39 011 2285424 1652 Email: ivano.guardini@telecomitalia.it 1654 Elena Demaria 1655 Telecom Italia Lab 1656 via G. Reiss Romoli, 274 1657 10148 TORINO 1658 Italy 1659 Phone: +39 011 2285403 1660 Email: elena.demaria@telecomitalia.it 1662 Intellectual Property Statement 1664 The IETF takes no position regarding the validity or scope of any 1665 intellectual property or other rights that might be claimed to 1666 pertain to the implementation or use of the technology described in 1667 this document or the extent to which any license under such rights 1668 might or might not be available; neither does it represent that it 1669 has made any effort to identify any such rights. Information on the 1670 IETF's procedures with respect to rights in standards-track and 1671 standards-related documentation can be found in BCP-11. Copies of 1672 claims of rights made available for publication and any assurances of 1673 licenses to be made available, or the result of an attempt made to 1674 obtain a general license or permission for the use of such 1675 proprietary rights by implementors or users of this specification can 1676 be obtained from the IETF Secretariat. 1678 The IETF invites any interested party to bring to its attention any 1679 copyrights, patents or patent applications, or other proprietary 1680 rights which may cover technology that may be required to practice 1681 this standard. Please address the information to the IETF Executive 1682 Director. 1684 Full Copyright Statement 1686 Copyright (C) The Internet Society (2003). All Rights Reserved. 1688 This document and translations of it may be copied and furnished to 1689 others, and derivative works that comment on or otherwise explain it 1690 or assist in its implementation may be prepared, copied, published 1691 and distributed, in whole or in part, without restriction of any 1692 kind, provided that the above copyright notice and this paragraph are 1693 included on all such copies and derivative works. However, this 1694 document itself may not be modified in any way, such as by removing 1695 the copyright notice or references to the Internet Society or other 1696 Internet organizations, except as needed for the purpose of 1697 developing Internet standards in which case the procedures for 1698 copyrights defined in the Internet Standards process must be 1699 followed, or as required to translate it into languages other than 1700 English. 1702 The limited permissions granted above are perpetual and will not be 1703 revoked by the Internet Society or its successors or assignees. 1705 This document and the information contained herein is provided on an 1706 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1707 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1708 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1709 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1710 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1712 Acknowledgement 1714 Funding for the RFC Editor function is currently provided by the 1715 Internet Society.