Diameter Maintenance and H. Tschofenig Extensions (DIME) Siemens Internet-Draft February 27, 2006 Expires: August 31, 2006 Diameter MIPv6 Application for the Integrated Scenario draft-tschofenig-dime-mip6-integrated-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 31, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract A Mobile IPv6 node requires a home agent address, a home address, and IPsec security association with its home agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these parameters are statically configured. Ongoing work aims to make this information dynamically available to the mobile node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document defines a Diameter Tschofenig Expires August 31, 2006 [Page 1] Internet-Draft Diameter MIPv6 Integrated Scenario February 2006 application to facilitate Mobile IPv6 bootstrapping for the integrated scenario. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Command Codes and AVPs . . . . . . . . . . . . . . . . . . . . 7 4.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Advertising Application Support . . . . . . . . . . . . . 7 4.3. MIPv6-Bootstrapping-Request (MBR) . . . . . . . . . . . . 8 4.4. MIPv6-Bootstrapping-Answer (MBA) . . . . . . . . . . . . . 8 4.5. MIPv6-Home-Agent-Request (MHR) . . . . . . . . . . . . . . 9 4.6. MIPv6-Home-Agent-Answer (MHA) . . . . . . . . . . . . . . 9 4.7. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.7.1. Home Agent Address AVP . . . . . . . . . . . . . . . . 10 4.7.2. Home Agent FQDN AVP . . . . . . . . . . . . . . . . . 10 4.7.3. Home Link Prefix AVP . . . . . . . . . . . . . . . . . 10 4.7.4. Home Address AVP . . . . . . . . . . . . . . . . . . . 10 4.7.5. DNS Update Mobility Option Attribute . . . . . . . . . 10 4.7.6. MIPv6 Bootstrapping Feature Attribute . . . . . . . . 11 4.7.7. MIPv6 Security Association Parameters . . . . . . . . 11 5. Example Exchanges . . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Tschofenig Expires August 31, 2006 [Page 2] Internet-Draft Diameter MIPv6 Integrated Scenario February 2006 1. Introduction Mobile IPv6 specification [1] requires a Mobile Node (MN) to perform registration with a Home Agent with information about its current point of attachment (Care-of Address). The Home Agent creates and maintains binding between the MN's Home Address and the MN's Care-of Address. In order to register with a Home Agent, the MN needs to know some information such as, the Home Link prefix, the Home Agent Address, the Home Address, the Home Link prefix Length and security related information in order to later secure the Binding Update. The aforementioned set of information may be statically provisioned in the MN. However, static provisioning of this information has its drawbacks. It increases provisioning and network maintenance burden for the operator. Moreover, static provisioning does not allow load balancing, failover, opportunistic home link assignment etc. For example, the user may be accessing the network from a location that may be geographically far away from the preconfigured home link; the administrative burden to configure the MN's with the respective addresses is large and the ability to react on environmental changes is minimal. In these situations static provisioning may not be desirable. Dynamic assignment of Mobile IPv6 home registration information is a desirable feature for ease of deployment and network maintenance. For this purpose, the Diameter infrastructure, which is used for access authentication, can be leveraged to assign some or all of the necessary parameters. The Diameter server in the Access Service Provider (ASP) or in the Mobility Service Provider's (MSP) network may return these parameters to the AAA client. The AAA client might either be the NAS, in case of the integrated scenario, or the home agent, in case of the split scenario. The terms integrated and split are described in the terminology section and were introduced in [2]. Tschofenig Expires August 31, 2006 [Page 3] Internet-Draft Diameter MIPv6 Integrated Scenario February 2006 2. Terminology and Abbreviations The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [3]. General mobility terminology can be found in [4]. The following additional terms, as defined in [2], are used in this document: Access Service Authorizer (ASA): A network operator that authenticates a mobile node and establishes the mobile node's authorization to receive Internet service. Access Service Provider (ASP): A network operator that provides direct IP packet forwarding to and from the mobile node. Mobility Service Authorizer (MSA): A service provider that authorizes Mobile IPv6 service. Mobility Service Provider (MSP): A service provider that provides Mobile IPv6 service. In order to obtain such service, the mobile node must be authenticated and authorized to obtain the Mobile IPv6 service. Split scenario: A scenario where the mobility service and the network access service are authorized by different entities. Integrated Scenario: A scenario where the mobility service and the network access service are authorized by the same entity. Tschofenig Expires August 31, 2006 [Page 4] Internet-Draft Diameter MIPv6 Integrated Scenario February 2006 3. Overview This document addresses the authentication, authorization and accounting functionality required by for the MIPv6 bootstrapping as outlined in the MIPv6 bootstrapping problem statement document (see [2]). This document focuses on the AAA functionality for the integrated scenario. The AAA interaction for the split scenario seem to be much simpler and described in [10]. The subsequent text outlines the AAA interaction between the participating entities in the integrated scenario. In the integrated scenario MIPv6 bootstrapping is provided as part of the network access authentication procedure. Figure 1 shows the participating entities. +---------------------------+ +-----------------+ |Access Service Provider | |ASA/MSA/(/MSP) | |(Mobility Service Provider)| | | | | | | | +--------+ | | +--------+ | | |Local | Diameter | | |Home | | | |Diameter|<----------------------> Diameter| | | |Proxy | | | |Server | | | +--------+ | | +--------+ | | ^ | | ^ | | | | |Diameter| | | | | | | | | |Diameter | | v | | | +-------+ | | +-------+ | | | Diameter |Home | | | |Home | | | | +------->|Agent | | | |Agent | | | | | |in ASP | | | | | | | v v +-------+ | | +-------+ | +-------+ IEEE | +-----------+ +-------+ | +-----------------+ |Mobile | 802.1X | |NAS/Relay | |DHCPv6 | | |Node |----------+-|Diameter |---|Server | | | | PANA,... | |Client | | | | +-------+ DHCP | +-----------+ +-------+ | +---------------------------+ Figure 1: Mobile IPv6 Bootstrapping: Integrated scenario In the typical Mobile IPv6 access scenario as shown above, the MN attaches in a Access Service Provider's network. During this network attachment procedure, the NAS/Diameter client interacts with the mobile node. As shown in Figure 1, the authentication and authorization happens via a Diameter infrastructure. Tschofenig Expires August 31, 2006 [Page 5] Internet-Draft Diameter MIPv6 Integrated Scenario February 2006 At the time of authorizing the user for IPv6 access, the Diameter server in the MSA detects that the user is authorized for Mobile IPv6 access. Based on the MSA's policy, the Diameter server may allocate several parameters to the MN for use during the subsequent Mobile IPv6 protocol interaction with the home agent. Depending on the details of the solution interaction with the DHCPv6 server may be required, as described in [5]. Tschofenig Expires August 31, 2006 [Page 6] Internet-Draft Diameter MIPv6 Integrated Scenario February 2006 4. Command Codes and AVPs This section defines command codes and AVPs for usage of Diameter for bootstrapping MIPv6 in the split scenario. 4.1. Command Codes This document introduces four new command codes: o MIPv6-Bootstrapping-Request (MBR) (Code TBD) o MIPv6-Bootstrapping-Answer (MBA) (Code TBD) o MIPv6-Home-Agent-Request (MHR) (Code TBD) o MIPv6-Home-Agent-Answer (MHA) (Code TBD) In addition, the following Diameter Base protocol messages are used with this application: Command-Name Abbrev. Code Reference Accounting-Request ACR 271 RFC 3588 Accounting-Request ACR 271 RFC 3588 Accounting-Answer ACA 271 RFC 3588 Re-Auth-Request RAR 258 RFC 3588 Re-Auth-Answer RAA 258 RFC 3588 Abort-Session-Request ASR 274 RFC 3588 Abort-Session-Answer ASA 274 RFC 3588 Session-Term-Request STR 275 RFC 3588 Session-Term-Answer STA 275 RFC 3588 4.2. Advertising Application Support Diameter nodes conforming to this specification MAY advertise support by including the value of (TBD) in the Auth-Application-Id or the Acct-Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer command [6]. The value of TBD MUST be used as the Application-Id in all MBR/MBA and MHR/MHA commands. The value of zero (0) SHOULD be used as the Application-Id in all STR/STA, ACR/ACA, ASR/ASA, and RAR/RAA commands, because these commands are defined in the Diameter base protocol and no additional mandatory AVPs for those commands are defined in this document. Tschofenig Expires August 31, 2006 [Page 7] Internet-Draft Diameter MIPv6 Integrated Scenario February 2006 4.3. MIPv6-Bootstrapping-Request (MBR) The MIPv6-Bootstrapping-Request message (MBR) indicated by the Command- Code field (see Section 3 of [6]) set to TBD and 'R' bit set in the Command Flags field is used by Diameter clients to request home agent assignment, to authorize for mobility service usage and optionally to indicate the support of local home agent assignment. The MBR message MAY carry the DNS Update Mobility Option and the MIPv6 Bootstrapping Feature attribute. The message format, presented in ABNF form [7], is defined as follows: ::= < Diameter Header: XXX, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Request-Type } [ Destination-Host ] [ User-Name ] [ DNS Update Mobility Option ] [ MIPv6 Bootstrapping Feature ] * [ AVP ] 4.4. MIPv6-Bootstrapping-Answer (MBA) The MIPv6-Bootstrapping-Answer (MBA) message, indicated by the Command- Code field set to TBD and 'R' bit cleared in the Command Flags field is sent in response to the MIPv6-Bootstrapping-Request message (MBR). If the mobility service is successfully authorized and the Diameter server was able to fulfill the bootstrapping request (if needed) then the response MAY include the DNS Update Mobility Option, Home Address, Home Link Prefix, Home Agent FQDN and the Home Agent Address AVP. The message format is defined as follows: Tschofenig Expires August 31, 2006 [Page 8] Internet-Draft Diameter MIPv6 Integrated Scenario February 2006 ::= < Diameter Header: XXX, PXY > < Session-Id > { Auth-Application-Id } { Auth-Request-Type } { Result-Code } { Origin-Host } { Origin-Realm } [ DNS Update Mobility Option ] [ Home Address ] [ Home Link Prefix ] [ Home Agent FQDN ] [ Home Agent Address ] * [ AVP ] 4.5. MIPv6-Home-Agent-Request (MHR) The MIPv6-Home-Agent-Request (MHR) message, indicated by the Command- Code field set to TDB and 'R' bit set in the Command Flags field is used by Diameter entity (acting as a Diameter client) to interact with the home agent. (acting as a Diameter server). The message MUST carry the MIPv6 Security Association Parameters. Additionally, the Diameter client might provide the Home Address and the Home Link Prefix to the Diameter server. The message format is defined as follows: ::= < Diameter Header: XXX, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Request-Type } [ Destination-Host ] [ Home Address ] [ Home Link Prefix ] [ MIPv6 Security Association ] * [ AVP ] 4.6. MIPv6-Home-Agent-Answer (MHA) The MIPv6-Home-Agent-Answer (MHA) message, indicated by the Command- Code field set to TBD and 'R' bit cleared in the Command Flags field is sent in response to the MIPv6-Home-Agent-Request (MHR) message for confirmation of the result of MIPv6 HA bootstrapping. This message MAY contain the Home Link Prefix and the Home Address. Tschofenig Expires August 31, 2006 [Page 9] Internet-Draft Diameter MIPv6 Integrated Scenario February 2006 The message format is defined as follows: ::= < Diameter Header: XXX, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Result-Code } [ Home Address ] [ Home Link Prefix ] * [ AVP ] 4.7. AVPs 4.7.1. Home Agent Address AVP The Diameter server MAY decide to assign a Home Agent to the MN that is in close proximity to the point of attachment (e.g., determined by the NAS-ID). There may be other reasons for dynamically assigning Home Agents to the MN, for example to share the traffic load. The AVP also contains the prefix length so that the MN can easily infer the Home Link prefix from the Home Agent address. 4.7.2. Home Agent FQDN AVP The Diameter server MAY assign an FQDN of the home address to the MN. The mobile node can perform DNS query with the FQDN to derive the home agent address. 4.7.3. Home Link Prefix AVP For the same reason as the HA assignment, the Diameter server MAY assign a Home Link that is in close proximity to the point of attachment (NAS-ID). The MN can perform [1] specific procedures to discover other information for Mobile IPv6 registration. 4.7.4. Home Address AVP The Diameter server MAY assign a Home Address to the MN. This allows the network operator to support mobile devices that are not configured with static addresses. The attribute also contains the prefix length so that the MN can easily infer the Home Link prefix from the Home Agent address. 4.7.5. DNS Update Mobility Option Attribute By using this payload the Diameter client instructs the Diameter Tschofenig Expires August 31, 2006 [Page 10] Internet-Draft Diameter MIPv6 Integrated Scenario February 2006 server to perform a dynamic DNS update. When this payload is included in the reverse direction, i.e., from the Diameter server to the Diameter client, it informs about the status of the dynamic DNS update. When the payload is sent from the Diameter client to the Diameter server then the response MUST include the DNS Update Mobility Option AVP. 4.7.6. MIPv6 Bootstrapping Feature Attribute By using this payload the Diameter client indicates to the Diameter server certain capabilities and features. For example, the Diameter client might want to indicate that local Home Agent assignment can be provided. Local-Home-Agent-Assignment: This flag is set to 1 when the Diameter client knows that a local home agent can be provided for the mobile node. Whether a local home agent can be provided depends on the functionality offered by the visited network and configured to the Diameter client. 4.7.7. MIPv6 Security Association Parameters This payload is used by the Diameter entity to provision keying material in a push fashion to the home agent. This AVP includes keying material, lifetime and key name information. Security parameter bootstrapping can be provided for IKEv2 [8], IKEv1 or for the MIPv6-AUTH protocol. [Editor's Note: A future version of this document will provide detailed AVP formats.] Tschofenig Expires August 31, 2006 [Page 11] Internet-Draft Diameter MIPv6 Integrated Scenario February 2006 5. Example Exchanges The following section shows a basic message flow with dynamic Home Agent assignment in the user's home network. The MBR / MBA message exchange illustrates the communication between the Diameter client and the Diameter server to initiate the bootstrapping procedure. The interaction between the Home Diameter server and the Home Agent (for HA bootstrapping in the home network) is depicted with the MHR / MHA exchange. Visited Diameter Home Diameter Mobile Node Diameter Client Proxy AAAh Server Home Agent ----------- ----------- ------------ ---------- ---------- initiate network access (1) (2) MBR-------------> (3) MBR------------> (4) MHR-------> <------(5) MHA <---------(6) MBA <------------(7) MBA Figure 7: Basic Boostrapping Scenario [Editor's Note: A future version of this document will provide additional examples.] Tschofenig Expires August 31, 2006 [Page 12] Internet-Draft Diameter MIPv6 Integrated Scenario February 2006 6. Security Considerations The security considerations for the Diameter interaction required to accomplish the integrated scenario are described in [5] . Additionally, the security consideratios of the Diameter base protocol [6], Diameter NASREQ [11] / Diameter EAP [12] (with respect to network access authentication and the transport of keying material) are applicable to this document. Tschofenig Expires August 31, 2006 [Page 13] Internet-Draft Diameter MIPv6 Integrated Scenario February 2006 7. Acknowledgements This document is heavily based on the ongoing work for RADIUS MIPv6 interaction. Hence, credits go to Kuntal Chowdhury and Avi Lior for their work with draft-chowdhury-mip6-radius-00.txt. Furthermore, the author would like to thank the authors of draft-le-aaa-diameter-mobileipv6-04.txt (Franck Le, Basavaraj Patil, Charles E. Perkins, Stefano Faccin) for their work in context of MIPv6 Diameter interworking. Their work influenced this document. Parts of this document are a byproduct of the ENABLE Project, partially funded by the European Commission under its Sixth Framework Programme. It is provided "as is" and without any express or implied warranties, including, without limitation, the implied warranties of fitness for a particular purpose. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the ENABLE Project or the European Commission. Tschofenig Expires August 31, 2006 [Page 14] Internet-Draft Diameter MIPv6 Integrated Scenario February 2006 8. Contributors Add your name here. Tschofenig Expires August 31, 2006 [Page 15] Internet-Draft Diameter MIPv6 Integrated Scenario February 2006 9. Open Issues A number of open issues have been identified during the work on this document. This document is incomplete since the AAA interaction for MIPv6 bootstrapping is still at an early stage. The following aspects require further discussion: o The details of the Diameter bootstrapping with respect to security. o AVP formats are not yet provided and a table of occurance is missing. o The IANA consideration section is empty. o Diameter Client/Server Behavior needs to be specified explicitly. o More examples are useful. o Alignment with the ongoing RADIUS MIPv6 bootstrapping needs to be ensured. Tschofenig Expires August 31, 2006 [Page 16] Internet-Draft Diameter MIPv6 Integrated Scenario February 2006 10. References 10.1. Normative References [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [2] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping Mobile IPv6", draft-ietf-mip6-bootstrap-ps-04 (work in progress), February 2006. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [4] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [5] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for the Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-00 (work in progress), October 2005. [6] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [7] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [8] Dupont, F. and V. Devarapalli, "Mobile IPv6 Operation with IKEv2 and the revised IPsec", draft-ietf-mip6-ikev2-ipsec-04 (work in progress), October 2005. [9] Giaretta, G., "Goals for AAA-HA interface", draft-ietf-mip6-aaa-ha-goals-01 (work in progress), January 2006. 10.2. Informative References [10] Tschofenig, H., "Mobile IPv6 Bootstrapping using Diameter", draft-tschofenig-mip6-aaa-ha-diameter-01 (work in progress), October 2005. [11] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005. [12] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. Tschofenig Expires August 31, 2006 [Page 17] Internet-Draft Diameter MIPv6 Integrated Scenario February 2006 [13] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", draft-ietf-mip6-bootstrapping-split-01 (work in progress), October 2005. [14] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [15] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. Tschofenig Expires August 31, 2006 [Page 18] Internet-Draft Diameter MIPv6 Integrated Scenario February 2006 Author's Address Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com Tschofenig Expires August 31, 2006 [Page 19] Internet-Draft Diameter MIPv6 Integrated Scenario February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Tschofenig Expires August 31, 2006 [Page 20]