idnits 2.17.00 (12 Aug 2021) /tmp/idnits11640/draft-tschofenig-mip6-aaa-ha-diameter-00.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 414. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 404. ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack 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 (July 11, 2005) is 6158 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 317, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 344, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3588 (ref. '1') (Obsoleted by RFC 6733) -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-03) exists of draft-ietf-mip6-aaa-ha-goals-00 == Outdated reference: draft-ietf-aaa-diameter-nasreq has been published as RFC 4005 == Outdated reference: draft-ietf-aaa-eap has been published as RFC 4072 == Outdated reference: draft-ietf-aaa-diameter-cc has been published as RFC 4006 == Outdated reference: A later version (-05) exists of draft-alfano-aaa-qosprot-02 == Outdated reference: A later version (-04) exists of draft-giaretta-mip6-authorization-eap-02 == Outdated reference: draft-ietf-aaa-diameter-sip-app has been published as RFC 4740 Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobility for IPv6 (mip6) H. Tschofenig 3 Internet-Draft T. Tsenov 4 Expires: January 12, 2006 Siemens 5 G. Giaretta 6 TILab 7 J. Bournelle 8 GET/INT 9 July 11, 2005 11 Diameter applicability for AAA-HA Interface in Mobile IPv6 12 draft-tschofenig-mip6-aaa-ha-diameter-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 12, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 In Mobile IPv6 deployment a need for interface between the Home Agent 46 and the AAA infrastructure of the Mobile Service Provider (MSP) and 47 the Mobility Service Authorizer (MSA) has been identified. This 48 interface should meet a list of requirements. This document provides 49 an overview description of the functionalities and design of Diameter 50 protocol which could meet the specified goals. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.1 General goals . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1.1 G1.1 - G1.4 Security . . . . . . . . . . . . . . . . . 5 59 3.1.2 Dead peer detection - the AAA-HA interface should 60 support inactive peer detection. . . . . . . . . . . . 5 61 3.2 Service Authorization . . . . . . . . . . . . . . . . . . 5 62 3.2.1 G2.1. The AAA-HA interface should allow the use of 63 Network Access Identifier (NAI) to identify the 64 mobile node. . . . . . . . . . . . . . . . . . . . . . 5 65 3.2.2 G2.2. The HA should be able to query the AAAH 66 server to verify Mobile IPv6 service authorization 67 for the mobile node. . . . . . . . . . . . . . . . . . 6 68 3.2.3 G2.3. The AAAH server should be able to enforce 69 explicit operational limitations and authorization 70 restrictions on the HA.( e.g. packet filters, QoS 71 parameters). . . . . . . . . . . . . . . . . . . . . . 6 72 3.2.4 G2.4 - G2.6. Issues addressing the maintenance of 73 a Mobile IPv6 session by the AAAH server, 74 e.g. authorization lifetime, extension of the 75 authorization lifetime and explicit 76 session termination by the AAAH server side. . . . . . 6 77 3.2.5 G2.7. The AAAH server should be able to retrieve 78 the Mobile IPv6 state associated to a specific MN 79 from the correspondent HA. This may be useful to 80 periodically verify the Mobile IPv6 service status. . 7 81 3.3 Accounting - G3.1. The AAA-HA interface must support 82 the transfer of accounting records needed for service 83 control and charging . . . . . . . . . . . . . . . . . . . 7 84 3.4 Mobile Node Authentication (G4.1. and G4.2.) . . . . . . . 7 85 3.5 Provisioning of configuration parameters . . . . . . . . . 8 86 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 5. Security considerations . . . . . . . . . . . . . . . . . . . 10 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 8.1 Normative References . . . . . . . . . . . . . . . . . . . 13 92 8.2 Informative References . . . . . . . . . . . . . . . . . . 13 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 94 Intellectual Property and Copyright Statements . . . . . . . . 15 96 1. Introduction 98 In Mobile IPv6 deployment, authentication, authorization and 99 accounting issues in the protocol operations are approached by 100 definition of an interface between the Home Agent (HA) and the AAA 101 infrastructure of the Mobility Service Provider (MSP). [3] document 102 presents a number of bootstrapping scenarios using the AAA-HA 103 interface and defines a list of requirements that the interface 104 should cover. This document deals with the functionalities provided 105 by Diameter protocol as a AAA protocol applicable at the discussed 106 interface. 108 2. Motivation 110 Designed to cover network access requirements for AAA protocols [1], 111 Diameter protocol provides a framework for applications offering AAA 112 services. This design approach gives to the protocol extensibility, 113 interoperability and flexibility in offering AAA solutions in 114 comparison to other AAA protocols. Support of definition of new 115 application Ids, commands and AVPs provides extensibility. 116 Recommended re-use of commands and AVPs and careful consideration of 117 the level of AVP's support provides interoperability. Usage of IPsec 118 and TLS for transport hop-by-hop security, possible support for AVP 119 integrity and confidentiality and usage of peer-to-peer model (any 120 Diameter node can initiate a request message) provide flexibility of 121 the Diameter AAA applications to fit to specific requirements. 123 In the following sections we try to specify by which means a possible 124 Diameter application would cover the requirements for the AAA-HA 125 interface specified in [3]. 127 3. Goals 129 In presentation of the analysis of goals and possible design 130 solutions by Diameter we follow the classification, labels and naming 131 assigned in the document [3], where these goals are identified. 132 Since several of the issues might be addressed in similar way or by 133 similar Diameter functionality, we have grouped these issues and have 134 given a general description of the groups. 136 3.1 General goals 138 3.1.1 G1.1 - G1.4 Security 140 As design goals for an AAA interface, G1.1 - G1.4 goals specify 141 standard requirements for a AAA protocol - mutual authentication of 142 the peers, integrity, replay protection and confidentiality. Various 143 authentication methods might be used, many of them are already 144 supported by a Diameter NASREQ and EAP applications [4],[5] and could 145 be re-used. IPsec or TLS provide the hop-by-hop security. Combined, 146 they should be able to provide the range of security services 147 required for the AAA-HA interface. 149 3.1.2 Dead peer detection - the AAA-HA interface should support 150 inactive peer detection. 152 Two possible approaches might be considered here: 154 o AAAH server and Home Agent establish a transport connection 155 between each other. In this case Diameter heartbeat messages 156 called Watch-Dog-Request/Answer, which are exchanged over this 157 connection to test for its aliveness, may be used to detect 158 inactivity in any of the two Diameter peers. 160 o AAAH server and Home Agent do not have transport connection. In 161 this case inactive peer detection functionality should be provided 162 into the Diameter session - service stateless Diameter sessions 163 might be established between the AAAH server and the range of 164 MSP's Home Agents for detecting HAs availability. 166 3.2 Service Authorization 168 3.2.1 G2.1. The AAA-HA interface should allow the use of Network Access 169 Identifier (NAI) to identify the mobile node. 171 Identification by User-Name AVP [1], which has a format consistent 172 with the NAI specifications, is common for Diameter applications. 173 Diameter provides functionality for routing of Diameter requests 174 based on the information included in the User-Name AVP. 176 3.2.2 G2.2. The HA should be able to query the AAAH server to verify 177 Mobile IPv6 service authorization for the mobile node. 179 Based on the peer-to-peer model, Diameter design gives the 180 functionality that any Diameter node can initiate a request message. 181 This, combined with the support of EAP, would provide flexible 182 solutions for this issue. Currently several Diameter application 183 standardized or under work-in-progress address different types of 184 authorization - network access [4], credit control [6], quality of 185 service [7]. This might allow re-use of present AVPs over the 186 AAAH-HA interface. 188 3.2.3 G2.3. The AAAH server should be able to enforce explicit 189 operational limitations and authorization restrictions on the 190 HA.( e.g. packet filters, QoS parameters). 192 Several present Diameter applications, standardized or under work-in- 193 progress address an operation and authorization control over specific 194 services and have defined appropriate AVPs. NAS-Filter-Rule AVP, 195 defined by Diameter NASREQ application [4], provides IP packet filter 196 description. QoS-Filter-Rule AVP defined by Diameter NASREQ 197 application and QSPEC AVP defined by Diameter QoS Authorization [7] 198 provide QoS parameter description. Credit Control application [6] 199 provides cost control over requested services. AVPs may be re-used 200 for providing required functionality over the AAAH-HA interface. 201 This, combined with the possibility that any node can initiate 202 request message, gives control to the AAAH server over HA's 203 functionality. 205 3.2.4 G2.4 - G2.6. Issues addressing the maintenance of a Mobile IPv6 206 session by the AAAH server, e.g. authorization lifetime, 207 extension of the authorization lifetime and explicit 208 session termination by the AAAH server side. 210 Diameter base protocol provides a powerful set of commands and AVPs 211 for management of the authorization and accounting sessions. A 212 number of AVPs (Auth-Lifetime-AVP, Grace-Period-AVP, Session-Timeout- 213 AVP) handle the duration (in time) of an authorization session [1]. 214 Additional AVPs for measuring the authorization duration in units 215 different that time are specified too [6]. Exchanging of application 216 specific authorization request/answer messages provides extension of 217 the authorization session. Initiation of the re-authorization by 218 both sides could be supported. Both sides could initiate session 219 termination, by using Diameter Session Termination and Abort Session 220 messages. 222 All these are applied to the Diameter session used for authorization 223 of a Mobile IPv6 session and need to be applied appropriately to this 224 Mobile IPv6 session too. 226 3.2.5 G2.7. The AAAH server should be able to retrieve the Mobile IPv6 227 state associated to a specific MN from the correspondent HA. This 228 may be useful to periodically verify the Mobile IPv6 service 229 status. 231 This issue has two sides: 233 1. How the AAAH should know which HA to contact to retrieve current 234 status of MN's Mobile IPv6 service in case of stateless MSP 235 architecture and several servicing AAA servers? - As analyzed 236 into the [8], this need would be required for re-authorization 237 and in this case the provision of HA info could be provided from 238 the MN during the re-authentication session between NM and AAAH 239 server. 241 2. Once having the HA info, AAAH should contact it to verify the 242 status of MN's Mobile IPv6 service. - This could be performed by 243 Request/Response messages initiated by the AAAH server. This 244 functionality is supported by the Diameter protocol and currently 245 is applied into Diameter SIP application for updating user 246 profiles at Diameter client (i.e., SIP server). 248 3.3 Accounting - G3.1. The AAA-HA interface must support the transfer 249 of accounting records needed for service control and charging 251 Diameter accounting protocol provides a variety of options - real- 252 time accounting, event/session-type accounting records, fault 253 resilience, correlation of accounting records. Requirements for the 254 accounting services over AAAH-HA interface are standard. Definition 255 or re-used of AVPs for the specific accounting records combined with 256 the functionality of the Diameter accounting protocol should provide 257 desired accounting services. 259 3.4 Mobile Node Authentication (G4.1. and G4.2.) 261 These issues require the functionality of AAAH server working as a 262 back-end authentication server and HA working as NAS and EAP 263 authenticator in pass-through mode for providing a mobile node 264 authentication. These functionalities are provided by Diameter 265 NASREQ and EAP applications, and might be re-used at the AAAH-AH 266 interface.[4], [5] 268 3.5 Provisioning of configuration parameters 270 Issues G5.1 - G5.3 are related to capability of exchanging and 271 negotiating of operational parameters for Mobile IPv6 protocol 272 bootstrapping and providing appropriate security level for this 273 information. 275 Diameter provides secure transport by means of IPsec, TLS and 276 possible AVPs integrity and confidentiality support (currently with 277 no interest from the community). Several AVPs could be re-used for 278 carrying the operational parameters for the Mobile IPv6 279 bootstrapping. Framed-IPv6-Prefix AVP, Login-IPv6-Host AVP, Framed- 280 Interface-Id AVP, Framed-IPv6-Route AVP defined by NASREQ might be 281 used for home address provision and AVPs defined in EAP application 282 might be used for key transport [5]. 284 4. Conclusion 286 This document provides information about the Diameter usage for the 287 AAA-HA interface. It is not yet complete since (a) the goals for the 288 AAA-HA interface [3] are still work in progress and (b) solutions for 289 all scenarios are not yet available. A final conclusion about the 290 required AVPs cannot be provided at this point in time. 292 5. Security considerations 294 [Editor's Note: Since the document is not complete it is necessary to 295 state that the security consideration section is incomplete as well. 296 Hence, it is only possible to refer to the security issues raised in 297 the Mobile IPv6 and Diameter protocol related documents mentioned 298 here, such as [8], [3] and [1].] 300 6. IANA Considerations 302 This document does not require actions to be taken by the IANA. 304 7. Acknowledgements 306 We would like to thank the MIPv6 Bootstrapping Design Team for their 307 comments. Additionally, we would to thank Junghoon Jee for his 308 feedback. 310 8. References 312 8.1 Normative References 314 [1] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 315 "Diameter Base Protocol", RFC 3588, September 2003. 317 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 318 Levels", March 1997. 320 8.2 Informative References 322 [3] Giaretta, G., "Goals for AAA-HA interface", 323 draft-ietf-mip6-aaa-ha-goals-00 (work in progress), May 2005. 325 [4] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 326 Network Access Server Application", 327 draft-ietf-aaa-diameter-nasreq-17 (work in progress), July 2004. 329 [5] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 330 Authentication Protocol (EAP) Application", 331 draft-ietf-aaa-eap-10 (work in progress), November 2004. 333 [6] Mattila, L., Koskinen, J., Stura, M., Loughney, J., and H. 334 Hakala, "Diameter Credit-control Application", 335 draft-ietf-aaa-diameter-cc-06 (work in progress), August 2004. 337 [7] Alfano, F., "Diameter Quality of Service Application", 338 draft-alfano-aaa-qosprot-02 (work in progress), February 2005. 340 [8] Giaretta, G., "MIPv6 Authorization and Configuration based on 341 EAP", draft-giaretta-mip6-authorization-eap-02 (work in 342 progress), October 2004. 344 [9] Garcia-Martin, M., "Diameter Session Initiation Protocol (SIP) 345 Application", draft-ietf-aaa-diameter-sip-app-07 (work in 346 progress), March 2005. 348 Authors' Addresses 350 Hannes Tschofenig 351 Siemens 352 Otto-Hahn-Ring 6 353 Munich, Bavaria 81739 354 Germany 356 Email: Hannes.Tschofenig@siemens.com 358 Tseno Tsenov 359 Siemens 360 Otto-Hahn-Ring 6 361 Munich, Bayern 81739 362 Germany 364 Email: tseno.tsenov@mytum.de 366 Gerardo Giaretta 367 Telecom Italia Lab 368 via G. Reiss Romoli, 274 369 TORINO, 10148 370 Italy 372 Email: gerardo.giaretta@tilab.com 374 Julien Bournelle 375 GET/INT 376 9 rue Charles Fourier 377 Evry 91011 378 France 380 Email: julien.bournelle@int-evry.fr 382 Intellectual Property Statement 384 The IETF takes no position regarding the validity or scope of any 385 Intellectual Property Rights or other rights that might be claimed to 386 pertain to the implementation or use of the technology described in 387 this document or the extent to which any license under such rights 388 might or might not be available; nor does it represent that it has 389 made any independent effort to identify any such rights. Information 390 on the procedures with respect to rights in RFC documents can be 391 found in BCP 78 and BCP 79. 393 Copies of IPR disclosures made to the IETF Secretariat and any 394 assurances of licenses to be made available, or the result of an 395 attempt made to obtain a general license or permission for the use of 396 such proprietary rights by implementers or users of this 397 specification can be obtained from the IETF on-line IPR repository at 398 http://www.ietf.org/ipr. 400 The IETF invites any interested party to bring to its attention any 401 copyrights, patents or patent applications, or other proprietary 402 rights that may cover technology that may be required to implement 403 this standard. Please address the information to the IETF at 404 ietf-ipr@ietf.org. 406 Disclaimer of Validity 408 This document and the information contained herein are provided on an 409 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 410 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 411 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 412 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 413 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 414 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 416 Copyright Statement 418 Copyright (C) The Internet Society (2005). This document is subject 419 to the rights, licenses and restrictions contained in BCP 78, and 420 except as set forth therein, the authors retain all their rights. 422 Acknowledgment 424 Funding for the RFC Editor function is currently provided by the 425 Internet Society.