idnits 2.17.1 draft-tschofenig-dime-mip6-split-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 480. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 457. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 470. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 60: '...etection - the HA-AAA interface SHOULD...' RFC 2119 keyword, line 63: '...HA-AAA interface SHOULD allow the use ...' RFC 2119 keyword, line 66: '...2. G2.2. The HA SHOULD be able to que...' RFC 2119 keyword, line 69: '... The AAAH server SHOULD be able to enf...' RFC 2119 keyword, line 78: '...3.1. The HA-AAA interface MUST support...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 76 has weird spacing: '...xplicit sessi...' == Line 287 has weird spacing: '...xplicit sessi...' -- 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 6, 2006) is 6619 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: '6' is defined on line 391, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 396, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3588 (ref. '1') (Obsoleted by RFC 6733) == Outdated reference: A later version (-07) exists of draft-ietf-mip6-bootstrapping-split-01 ** Obsolete normative reference: RFC 4005 (ref. '5') (Obsoleted by RFC 7155) == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-00 == Outdated reference: A later version (-03) exists of draft-ietf-mip6-aaa-ha-goals-01 == Outdated reference: A later version (-04) exists of draft-giaretta-mip6-authorization-eap-02 Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintanence and H. Tschofenig 3 Extensions (DIME) Siemens 4 Internet-Draft T. Tsenov 5 Expires: September 7, 2006 6 G. Giaretta 7 TILab 8 J. Bournelle 9 GET/INT 10 March 6, 2006 12 Mobile IPv6 Bootstrapping using Diameter in the Split Scenario 13 draft-tschofenig-dime-mip6-split-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 7, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 In Mobile IPv6 deployment a need for an interaction between the Home 47 Agent, the AAA infrastructure of the Mobile Service Provider (MSP) 48 and the Mobility Service Authorizer (MSA) has been identified. This 49 document provides a description of the functionality that allows to 50 meet the goals outlined in the MIPv6 AAA Goals document. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Bootstrapping Mobile IPv6 in the Split Scenario . . . . . . . 5 57 4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 4.1. General goals . . . . . . . . . . . . . . . . . . . . . . 8 59 4.1.1. G1.1 - G1.4 Security . . . . . . . . . . . . . . . . . 8 60 4.1.2. Dead peer detection - the HA-AAA interface SHOULD 61 support inactive peer detection. . . . . . . . . . . . 8 62 4.2. Service Authorization . . . . . . . . . . . . . . . . . . 8 63 4.2.1. G2.1. The HA-AAA interface SHOULD allow the use of 64 Network Access Identifier (NAI) to identify the 65 mobile node. . . . . . . . . . . . . . . . . . . . . . 8 66 4.2.2. G2.2. The HA SHOULD be able to query the AAAH 67 server to verify Mobile IPv6 service authorization 68 for the mobile node. . . . . . . . . . . . . . . . . . 9 69 4.2.3. G2.3. The AAAH server SHOULD be able to enforce 70 explicit operational limitations and authorization 71 restrictions on the HA.( e.g. packet filters, QoS 72 parameters). . . . . . . . . . . . . . . . . . . . . . 9 73 4.2.4. G2.4 - G2.6. Issues addressing the maintenance of 74 a Mobile IPv6 session by the AAAH server, e.g. 75 authorization lifetime, extension of the 76 authorization lifetime and explicit session 77 termination by the AAAH server side. . . . . . . . . . 9 78 4.3. Accounting - G3.1. The HA-AAA interface MUST support 79 the transfer of accounting records needed for service 80 control and charging . . . . . . . . . . . . . . . . . . . 10 81 4.4. Mobile Node Authentication (G4.1.) . . . . . . . . . . . . 10 82 4.5. Provisioning of Configuration Parameters . . . . . . . . . 10 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 90 Intellectual Property and Copyright Statements . . . . . . . . . . 16 92 1. Introduction 94 In Mobile IPv6 deployment, authentication, authorization and 95 accounting issues in the protocol operations are approached by using 96 the AAA infrastructure. The [8] document presents a number of 97 bootstrapping scenarios using the HA-AAA interface and defines a list 98 of requirements that this interface should cover. This document 99 deals with the functional capabilities of the Diameter protocol as a 100 AAA protocol applicable for the split scenario. 102 Currently, two Mobile IPv6 bootstrapping solutions exist. In the 103 split scenario, only a HA-AAA interface is considered whereas in the 104 integrated scenario both NAS-AAA and HA-AAA interface need to be 105 addressed. 107 This document focuses only on the split scenario. A separate 108 document describes a Diameter application for bootstrapping MIPv6 for 109 the integrated scenario. 111 2. Motivation 113 Designed to cover network access requirements for AAA protocols [1], 114 Diameter protocol provides a framework for applications offering AAA 115 services. This design approach gives to the protocol extensibility, 116 interoperability and flexibility in offering AAA solutions in 117 comparison to other AAA protocols. Support of definition of new 118 application Ids, commands and AVPs provides extensibility. 119 Recommended re-use of commands and AVPs and careful consideration of 120 the level of AVP's support provides interoperability. Usage of IPsec 121 and TLS for transport hop-by-hop security, possible support for AVP 122 integrity and confidentiality and usage of peer-to-peer model (any 123 Diameter node can initiate a request message) provide flexibility of 124 the Diameter AAA applications to fit to specific requirements. 126 In the following sections we try to specify by which means a possible 127 Diameter application would cover the requirements for the HA-AAA 128 interface specified in [8]. 130 3. Bootstrapping Mobile IPv6 in the Split Scenario 132 In the split scenario for bootstrapping Mobile IPv6 [2], the MN 133 discovers HA through DNS mechanism. Then it uses IKEv2 [3] to setup 134 IPsec SAs. IKEv2 supports EAP to authenticate the Initiator and thus 135 the MN. As such, the MN can use its credentials (obtained from the 136 MSA) to be authenticated for the IPv6 mobility service. The HA MAY 137 rely on a EAP server co-located on a AAA server for this purpose. In 138 this case, a HA-AAA interface is needed. This interface MUST support 139 transport of EAP packets. 141 +----+ IKEv2 +----+ Diameter EAP +---+ 142 | MN |<----------->| HA |<-------------------->|AAA| 143 +----+ +----+ +---+ 145 Figure 1: Diameter EAP as the HA-AAA interface in Split 146 scenario 148 For this purpose, the HA can use Diameter EAP Application [4] (cf. 149 Figure 1). As shown in the previous section, this protocol fulfill 150 goals described in [8] 151 MN HA AAAH 152 -- -- ---- 153 IKE_SA_INIT 154 <------------------------------> 156 HDR, SK{IDi,[CERTREQ,] [IDr,] 157 SAi2, TSi, TSr} 158 -------------------------------> 159 DER (EAP-Response) 160 ------------------------> 161 DEA (EAP-Request) 162 <------------------------ 163 HDR, SK {IDr, [CERT,] AUTH, 164 EAP } 165 <------------------------------- 166 HDR, SK {EAP} 167 --------------------------------> 168 DER (EAP-Response) 169 ------------------------> 170 DEA (EAP-Request) 171 <------------------------ 172 HDR, SK{EAP-Request} 173 <------------------------------- 174 HDR, SK{EAP-Response} 175 --------------------------------> 176 DER (EAP-Response) 177 ------------------------> 178 ... ... 180 DEA (EAP-Success) 181 <------------------------ 182 HDR, SK{EAP-Success} 183 <------------------------------- 184 HDR, SK{AUTH} 185 -------------------------------> 186 HDR, SK {AUTH, SAr2, TSi, TSr } 187 <------------------------------- 189 Figure 2: IKEv2 Diameter EAP 191 MN and HA start with an IKE_SA_INIT to setup the IKE SA. The MN 192 indicates its desire to use EAP by not including the AUTH payload in 193 the third message. However it indicates its identity (e.g. NAI) by 194 using the IDi field. If the HA supports EAP for authentication, it 195 forwards the identity to the AAAH by sending a Diameter-EAP-Request 196 (DER) message containing the identity in the EAP-Payload AVP and in 197 the User-Name AVP. Based on this identity, the AAAH chooses an 198 authentication method and sends the first EAP-Request in the 199 Diameter-EAP-Answer message. During the EAP authentication phase, 200 the HA relays EAP packets between the MN and the AAAH. If the 201 authentication succeeds and if the MN is authorized to use Mobile 202 IPv6 service, the AAAH sends a DEA message containing the EAP-success 203 and the AAA-Key derived from the EAP authentication method . Note 204 that EAP authentication methods that do not derive keys are not 205 recommended. This key is used by both MN and HA to generate the AUTH 206 payload. In the latter message, MN and HA finish to setup IPsec SAs 207 for Mobile IPv6. 209 4. Goals 211 In presentation of the analysis of goals and possible design 212 solutions by Diameter we follow the classification, labels and naming 213 assigned in the document [8], where these goals are identified. 214 Since several of the issues might be addressed in similar way or by 215 similar Diameter functionality, we have grouped these issues and have 216 given a general description of the groups. 218 4.1. General goals 220 4.1.1. G1.1 - G1.4 Security 222 As design goals for an AAA interface, G1.1 - G1.4 goals specify 223 standard requirements for a AAA protocol - mutual authentication of 224 the peers, integrity, replay protection and confidentiality. IPsec 225 or TLS provide the hop-by-hop security. Combined, they SHOULD be 226 able to provide the range of security services required for the HA- 227 AAA interface. 229 4.1.2. Dead peer detection - the HA-AAA interface SHOULD support 230 inactive peer detection. 232 Two possible approaches might be considered here: 234 o AAAH server and Home Agent establish a transport connection 235 between each other. In this case Diameter heartbeat messages 236 called Device-Watchdog-Request/Answer [1], which are exchanged 237 over this connection to test for its aliveness, MAY be used to 238 detect inactivity in any of the two Diameter peers. 240 o AAAH server and Home Agent do not have transport connection. In 241 this case inactive peer detection functionality SHOULD be provided 242 into the Diameter session - service stateless Diameter sessions 243 might be established between the AAAH server and the range of 244 MSP's Home Agents for detecting HAs availability. 246 4.2. Service Authorization 248 4.2.1. G2.1. The HA-AAA interface SHOULD allow the use of Network 249 Access Identifier (NAI) to identify the mobile node. 251 Identification by User-Name AVP [1], which has a format consistent 252 with the NAI specifications, is common for Diameter applications. 253 Diameter provides functionality for routing of Diameter requests 254 based on the information included in the User-Name AVP. 256 4.2.2. G2.2. The HA SHOULD be able to query the AAAH server to verify 257 Mobile IPv6 service authorization for the mobile node. 259 Based on the peer-to-peer model, Diameter design gives the 260 functionality that any Diameter node can initiate a request message. 261 This, combined with the support of EAP, would provide flexible 262 solutions for this issue. Currently several Diameter application 263 standardized or under work-in-progress address different types of 264 authorization - network access [5], credit control [9], quality of 265 service [10]. This might allow re-use of present AVPs over the 266 AAAH-HA interface. 268 4.2.3. G2.3. The AAAH server SHOULD be able to enforce explicit 269 operational limitations and authorization restrictions on the 270 HA.( e.g. packet filters, QoS parameters). 272 Several present Diameter applications, standardized or under work-in- 273 progress address an operation and authorization control over specific 274 services and have defined appropriate AVPs. NAS-Filter-Rule AVP, 275 defined by Diameter NASREQ application [5], provides IP packet filter 276 description. QoS-Filter-Rule AVP defined by Diameter NASREQ 277 application and QSPEC AVP defined by Diameter QoS Authorization [10] 278 provide QoS parameter description. Credit Control application [9] 279 provides cost control over requested services. AVPs MAY be re-used 280 for providing required functionality over the AAAH-HA interface. 281 This, combined with the possibility that any node can initiate 282 request message, gives control to the AAAH server over HA's 283 functionality. 285 4.2.4. G2.4 - G2.6. Issues addressing the maintenance of a Mobile IPv6 286 session by the AAAH server, e.g. authorization lifetime, 287 extension of the authorization lifetime and explicit session 288 termination by the AAAH server side. 290 Diameter base protocol provides a powerful set of commands and AVPs 291 for management of the authorization and accounting sessions. A 292 number of AVPs (Auth-Lifetime-AVP, Grace-Period-AVP, Session-Timeout- 293 AVP) handle the duration (in time) of an authorization session [1]. 294 Additional AVPs for measuring the authorization duration in units 295 different that time are specified too [9]. Exchanging of application 296 specific authorization request/answer messages provides extension of 297 the authorization session. Initiation of the re-authorization by 298 both sides could be supported. Both sides could initiate session 299 termination, by using Diameter Session Termination and Abort Session 300 messages. 302 All these are applied to the Diameter session used for authorization 303 of a Mobile IPv6 session and need to be applied appropriately to this 304 Mobile IPv6 session too. 306 4.3. Accounting - G3.1. The HA-AAA interface MUST support the transfer 307 of accounting records needed for service control and charging 309 Diameter accounting protocol provides a variety of options - real- 310 time accounting, event/session-type accounting records, fault 311 resilience, correlation of accounting records. Requirements for the 312 accounting services over AAAH-HA interface are standard. Definition 313 or re-used of AVPs for the specific accounting records combined with 314 the functionality of the Diameter accounting protocol SHOULD provide 315 desired accounting services. 317 4.4. Mobile Node Authentication (G4.1.) 319 These issues require the functionality of AAAH server working as a 320 back-end authentication server and HA working as NAS and EAP 321 authenticator in pass-through mode for providing a mobile node 322 authentication. These functionalities are provided by Diameter 323 NASREQ and EAP applications, and might be re-used at the AAAH-AH 324 interface.[5], [4] 326 4.5. Provisioning of Configuration Parameters 328 Several AVPs could be re-used for carrying the home address of the NM 329 to the AAAH server. Framed-IPv6-Prefix AVP in conjunction with 330 Framed-Interface-Id AVP, Framed-IPv6-Route AVP or Login-IPv6-Host AVP 331 defined by NASREQ might be used for home address communication to the 332 AAAH [4]. 334 Even if not explicitly mentioned as goal the AAAH server needs in 335 some cases the FQDN from the MN if he should do an DNS update of his 336 behalf. The MN FQDN could be delivered during the IKEv2 exchange 337 between the HA and the MN (in the IDii field in IKE_AUTH). This FQDN 338 must, if not already known by the AAAH delivered to it. [Editor's 339 Note: An appropriate AVP for carrying the FQDN has not yet been 340 found.] 342 5. Security Considerations 344 [Editor's Note: Since the document is not complete it is necessary to 345 state that the security consideration section is incomplete as well. 346 Hence, it is only possible to refer to the security issues raised in 347 the Mobile IPv6 and Diameter protocol related documents mentioned 348 here, such as [11], [8] and [1].] 350 6. IANA Considerations 352 No new message formats or command codes are defined in this document. 354 7. Acknowledgements 356 We would like to thank the MIPv6 Bootstrapping Design Team for their 357 comments. Additionally, we would like to thank Junghoon Jee and 358 Florian Kohlmayer for their input. 360 Parts of this document are a byproduct of the ENABLE Project, 361 partially funded by the European Commission under its Sixth Framework 362 Programme. It is provided "as is" and without any express or implied 363 warranties, including, without limitation, the implied warranties of 364 fitness for a particular purpose. The views and conclusions 365 contained herein are those of the authors and should not be 366 interpreted as necessarily representing the official policies or 367 endorsements, either expressed or implied, of the ENABLE Project or 368 the European Commission. 370 8. References 372 8.1. Normative References 374 [1] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 375 "Diameter Base Protocol", RFC 3588, September 2003. 377 [2] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 378 draft-ietf-mip6-bootstrapping-split-01 (work in progress), 379 October 2005. 381 [3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 382 draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. 384 [4] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 385 Authentication Protocol (EAP) Application", RFC 4072, 386 August 2005. 388 [5] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 389 Network Access Server Application", RFC 4005, August 2005. 391 [6] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for 392 the Integrated Scenario", 393 draft-ietf-mip6-bootstrapping-integrated-dhc-00 (work in 394 progress), October 2005. 396 [7] Hamilton, M. and R. Wright, "Use of DNS Aliases for Network 397 Services", BCP 17, RFC 2219, October 1997. 399 8.2. Informative References 401 [8] Giaretta, G., "Goals for AAA-HA interface", 402 draft-ietf-mip6-aaa-ha-goals-01 (work in progress), 403 January 2006. 405 [9] Mattila, L., Koskinen, J., Stura, M., Loughney, J., and H. 406 Hakala, "Diameter Credit-control Application", 407 draft-ietf-aaa-diameter-cc-06 (work in progress), August 2004. 409 [10] Alfano, F., "Diameter Quality of Service Application", 410 draft-alfano-aaa-qosprot-05 (work in progress), October 2005. 412 [11] Giaretta, G., "MIPv6 Authorization and Configuration based on 413 EAP", draft-giaretta-mip6-authorization-eap-02 (work in 414 progress), October 2004. 416 Authors' Addresses 418 Hannes Tschofenig 419 Siemens 420 Otto-Hahn-Ring 6 421 Munich, Bavaria 81739 422 Germany 424 Email: Hannes.Tschofenig@siemens.com 426 Tseno Tsenov 427 Sofia, 428 Bulgaria 430 Email: tseno.tsenov@mytum.de 432 Gerardo Giaretta 433 Telecom Italia Lab 434 via G. Reiss Romoli, 274 435 TORINO, 10148 436 Italy 438 Email: gerardo.giaretta@tilab.com 440 Julien Bournelle 441 GET/INT 442 9 rue Charles Fourier 443 Evry 91011 444 France 446 Email: julien.bournelle@int-evry.fr 448 Intellectual Property Statement 450 The IETF takes no position regarding the validity or scope of any 451 Intellectual Property Rights or other rights that might be claimed to 452 pertain to the implementation or use of the technology described in 453 this document or the extent to which any license under such rights 454 might or might not be available; nor does it represent that it has 455 made any independent effort to identify any such rights. Information 456 on the procedures with respect to rights in RFC documents can be 457 found in BCP 78 and BCP 79. 459 Copies of IPR disclosures made to the IETF Secretariat and any 460 assurances of licenses to be made available, or the result of an 461 attempt made to obtain a general license or permission for the use of 462 such proprietary rights by implementers or users of this 463 specification can be obtained from the IETF on-line IPR repository at 464 http://www.ietf.org/ipr. 466 The IETF invites any interested party to bring to its attention any 467 copyrights, patents or patent applications, or other proprietary 468 rights that may cover technology that may be required to implement 469 this standard. Please address the information to the IETF at 470 ietf-ipr@ietf.org. 472 Disclaimer of Validity 474 This document and the information contained herein are provided on an 475 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 476 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 477 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 478 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 479 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 480 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 482 Copyright Statement 484 Copyright (C) The Internet Society (2006). This document is subject 485 to the rights, licenses and restrictions contained in BCP 78, and 486 except as set forth therein, the authors retain all their rights. 488 Acknowledgment 490 Funding for the RFC Editor function is currently provided by the 491 Internet Society.