INTERNET-DRAFT Hui Deng <draft-deng-mip6-bootstrap-bcf-00.txt> Hitachi(China) Date: October 2004 Qin Li BeiHang University Chongfeng Xie China Telecom Minghui Wang China Unicom Bootstrap Control Function mechanism for Mobile IPv6 Bootstrap draft-deng-mip6-bootstrap-bcf-00.txt Status of This Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document specifies a mechanism for Mobile IPv6 bootstrap procedure. By making a extension of MIP6 specification and using IKE to guarantee its security, this mechanism bring into a new component BCF(Bootstrap Control Function) to handle MNí¯s bootstrap procedure between MN and multiple HAs. Two new bootstrap messages Init and Ack has been defined to support bootstrap procedure. Deng, Li, Xie, Wang [Page i]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004 Table of Contents Status of This Memo ............................................... i 1. Introduction............................................... 1 2. Terminology................................................ 1 3. Architecture overview...................................... 2 4. Detailed Description....................................... 3 4.1 Seed Information....................................... 4 4.2 BCF (Bootstrap Control Function)....................... 4 4.3 Authentication Mechanism............................... 5 4.4 Dynamic Home Address Assignment........................ 5 4.5 Dynamic Home Agent Assignment.......................... 5 4.6 Interface between HA and BCF........................... 6 5. Detailed Message Format.................................... 6 5.1 MIPv6 Bootstrap Init Message Type...................... 6 5.1.1 Mobile Header Type............................... 6 5.1.2 Message Format................................... 6 5.2 MIPv6 Bootstrap Acknowledgement Message Type........... 7 5.2.1 Mobile Header Type............................... 7 5.2.2 Message Format................................... 7 5.3 Mobile Node Considerations............................. 8 5.4 Bootstrap Control Function Considerations.............. 8 5.5 Processing Considerations.............................. 8 6. Performance Implication in Wireless Networks............... 9 7. IANA Considerations........................................ 9 8. Security Considerations.................................... 9 9. Acknowledgements........................................... 9 References.................................................10 Authors' Addresses.........................................11 Intellectual Property and Copyright Statements.............12 Deng, Li, Xie, Wang [Page ii]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004 1. Introduction Mobile IPv6 [5] bootstrap [2] problem is about how to transfer MN's home address, Home Agent address, and security association between MN and HA. Current solution [7, 8] is mainly based on IASP scenario. These solutions are more applicable to the scenario which integrates the network access authentication with MIP6 bootstrap procedure. However MSP scenario might be more suitable for the current network operator since most network operator would like to separate the network access and MIP6 service management. For example, China Telecom and China Unicom consider separating initiation of mobility service with that of network access during their deployment plan. The protocol discussed later is applicable in a scenario where the ASP and the MSP is different provider as defined in [2]. By just making a small extension of MIP6 specification and using IKE to guarantee its security, this protocol bring into a new component BCF (Bootstrap Control Function) to handle MNí¯s bootstrap procedure between MN and multiple HAs. Bootstrap procedure can be realised by Home Agent Handover message defined in [3] as well as two new bootstrap messages and defined in this solution. 2. Terminology In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in RFC 2119 [1]. General mobility terminology can be found in [6]. The following Additional terms related to bootstrap problem of Mobile IPv6 are used here: ASP Access Service Provider IASP Integrated Access Service Provider MSP Mobility Service Provider AAA Authentication Authorization Accounting BCF Bootstrap Control Function NAI Network Acesss Indentifier BoI Bootstrap Init Message Deng, Li, Xie, Wang [Page 1]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004 BoA Bootstrap Acknowledge Message HAH Home Agent Handover Message 3. Architecture overview Visited Network | Home Network | | | +-------+ | | AAA | +-------+ | +-------+ +--------| HA1 | | | | +-------+ | | | | | | +------+ | +-------+ | +-------+ | MN |<--------|-------->| BCF |---+--------| HA2 | +------+ | +-------+ | +-------+ | | ... | | | | +-------+ | +--------| HAn | | +-------+ Figure 1. Architecture Figure 1 shows the network architecture of our proposed solution. Based on this architecture, MN send Mobile IPv6 Bootstrap Init message to a conceptual entity, called Bootstrap Control Function, the BoI message consists of NAI option, mobility message identification option and authentication option. BCF then athenticate this BoI message with the help of AAA for Mobility Service, and can assign a HoA, HA to the MN. BCF will response with a Mobile IPv6 Bootstrap Ack messages back to the MN which convey the MN's assigned HoA and HA. Deng, Li, Xie, Wang [Page 2]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004 4. Detailed Description MN +-----------------+ BCF +------------+ AAA +--+ HA1 HA2 HAn | | | | ------------------\ | | (1)| BoI with \ | | | auth & nai & id / | | | ------------------/ | | | | (2) | | | /------------\ | | | / authenticate \ | | | \ with AAA / | | | \------------/ | | | | + + | | (3) | | + + | | | /------------------ | (4)| / BoA with | | \ HoA & auth option | | \------------------ | | | | /------------------ | (5)| / HAH message | | \ defined in [3] | | \------------------ | | | (6) /----------------------------------------------\ / MIPv6 Binding Update \ \ & Binding ckowledgement / \----------------------------------------------/ Figure 2. Operational Flow Figure 3 shows an overview of the procedure defined to handle MIPv6 bootstrap for both MN and HAs. The whole bootstrap procedure can be divided in five steps, and the sixth step is the first Binding Update/Binding Ackowledgement messages between MN and selected HA: 1. This is a bootstrap init message initiated by MN. This BoI MUST include NAI option, mobility message identification option and authentication option. Deng, Li, Xie, Wang [Page 3]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004 2. The HA SHOULD extract MN-AAA authenticator, SPI[12] and the NAI from BoI message, generate AAA specific AVPs, and initiate the authentication procedure via AAA infrastructure. 3. After sucessfully athentication with AAA, BCF should do two things. The first one is to assign a HA for MN based on load balance information. The second one is to allocate either stateful or stateless HoA for MN, BCF MUST do a DAD check for the allocated HoA in home network. 4. BCF replies a Bootstrap Acknowledge message to MN. This BoA message MUST include HoA option, and also mobility message identification option and authentication option. 5. BCF replies a Home Agent Handover message [3] indicate the selected HA to MN. MN can extract HA address from HAH message. This step is the last bootstrap message of the whole procedure. 6. MN send the first BU message to the assigned HA. The HoA, HA address are provisioned in above bootstrap process. There are two authentication mechanism that can be applied to the BU message, as discussed in section 4.3 4.1 Seed Information In this bootstrap solution for an independent MSP, Bootstrap seed information is Mobility Service credential and related parameters, no nework access credential is needed. The seed information includes: 1. Host Identifier of BCF for MN to bootstrap from, that is, domain name, FQDN, or at least IP address of BCF host. 2. AAA credential for mutual authentication between MN and the BCF: a. Network access indentifier for mobility service b. Preshared secret between MN and AAA of Mobility Service 4.2 BCF (Bootstrap Control Function) In this solution, BCF and multiple HAs are under the same administrative domain. BCF and multiple HA should share a preconfigured trust relationship. Though the router advertisement message, BCF can get the load information of multiple HAs. When receiving BoI from MN, BCF will allocate a HA for MN based on those information. Deng, Li, Xie, Wang [Page 4]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004 Besides router advertisement message, BCF can also send Router Solicitation message to HA to get modified Home Agent List information. BCF will handle the bootstrap init message sent from MN, and allocate a HA and a HoA for MN. BCF will use HA handover mechanism to redirect a new HA for MN based on the solution defined in [3]. 4.3 Authentication Mechanism Athentication mechanism that can be applied in bootstrap signals between MN and BCF in this solution is Mobile IPv6 Authencation Protocol defined in [12] where MN-AAA authentication mobility option MUST be used in BoI message. In this solution, there are two kinds of athentication mechanism that can be applied in Binding Update message between MN and HA after a bootstrap procedure take place. The first one is IPSec + IKEv2. In this case, IKEv2 of MN and HA should support host authentication under AAA infrastructure. And the bootstrap credential of MN is also used as the IKE credential for mutual authentication between MN and HA. After bootstrap, MN will get the assgined HA address from BCF. Before MN send the first BU message to HA, an IKEv2 session will be established based on the AAA credential, and the result is IPSec SA negotiated to protect the BU message. The second one is also the Mobile IPv6 Authencation Protocol. In this case, MN could send the binding update message to HA with MN-AAA authentication mobility option, NAI option, and message indentification option as defined in [12]. 4.4 Dynamic Home Address Assignment Before BCF assign a HoA to MN, BCF will using DAD (Duplicate Address Detection) in the home network. After DAD checking, BCF will response a bootstrap acknowledgement message with an option for assigning MNí¯s HoA. 4.5 Dynamic Home Agent Assignment Here we can use HA load balance mechanism [3] for dynamic home agent assignment. Since MIP6 HA are not only responsible for the Deng, Li, Xie, Wang [Page 5]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004 registration of MN, but also tunneling the data packets to the MN even if there will be router optimization. Because each home agent have to maintains a separate HA list for each link, by extending this home agent list and modifying router advertisement message, load balance mechanism among multiple Has will be supported. BCF can assign a HA for MN based on this dynamical load balance mechanism among multiple HAs. 4.6 Interface between HA and BCF Router advertisement message has been used among multiple HAs. 5. Detailed Message Format 5.1 MIPv6 Bootstrap Init Message 5.1.1 Mobile Header Type BOOTSTRAP-INIT-TYPE to be defined by IANA. An 8-bit identifier of the type mobility header. 5.1.2 Message Format 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence # A 16-bit unsigned integer used by the Bootstrap Control Function to sequence Bootstrap Init message and by the mobile node to match a returned Boostrap Acknowledgement with this Bootstrap Init. Deng, Li, Xie, Wang [Page 6]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004 Reserved These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver. 5.2 MIPv6 Bootstrap Acknowledgement Message 5.2.1 Mobile Header Type BOOTSTRAP-ACK-TYPE to be defined by IANA. An 8-bit identifier of the type mobility header. 5.2.2 Message Format 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence # The Sequence Number in the Bootstrap Acknowledgement is copied from the Sequence Number field in the Bootstrap Acknowledgement with an outstanding bootstrap. Status 8-bit unsigned integer indicating the disposition of the Bootstrap. MIPV6-BOOTSTRAP-SUCCESS 0 MIPV6-BOOTSTRAP-BADCRED 127 MIPV6-BOOTSTRAP-ID-MISMATCH 126 Deng, Li, Xie, Wang [Page 7]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004 Reserved These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver. 5.3 Mobile Node Considerations MN must send Bootstrap Init message with MN-AAA mobility message authentication option (defined in section 6 of [12], subtype value is 2), mobility message identification option (define in section 7 of [12]). The MN SHOULD use NAI option to enable the BCF to make use of available AAA infrastructure which requires NAI. (defined in [10]). 5.4 Bootstrap Control Function Considerations BCF must send Bootstrap Acknowledge message with MN-AAA mobility message authentication option (defined in section 6 of [12], subtype value is 2), mobility message identification option (define in section 7 of [12]). BoA message MUST include HoA option and status code of MIPV6- BOOTSRAP-SUCCESS if the MN is authenticated by AAA server. Otherwise, an error result code MUST be given in status field of BoA message to indicate the reason as defined in section 5.5 5.5 Processing Considerations Mobility message identification option in BoI MUST be verified by BCF, to asure that the message has been generated recently by the MN, and it is not replayed by an attacker from some older BoI message. If this verification failed, BCF MUST send a Bootstrap Acknowledgement with error code MIPV6-BOOTSRAP-ID-MISMATCH in status field. The MN-AAA authentication mobility option MUST be verified by the AAA infrastructure that has the shared secret with the MN. The HA relays the authenticating information to the HAAA. The HA relies on the Home AAA for Mobility Service to admit or reject the home regis- tration request from the MN. If authentication failed, BCF MUST send a Bootstrap Acknowledgement with error code MIPV6-BOOTSRAP-BADCRED in status field. Deng, Li, Xie, Wang [Page 8]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004 6. Performance Implication in Wireless Networks By bringing into two new Mobile IPv6 message, and Handover message, this mechanism will not bring signal burdern to wireless network. BCF will act as the anchor point for multiple home agents, it also reduce some signal message among home network. 7. IANA Considerations This document defines two new messages type for bootstrap, o New Mobile Header Type, Bootstrap Init message, described in section 5.1 o New Mobile Header Type, Bootstrap Acknowledge message, described in section 5.2 8. Security Considerations This document described a AAA mechanism to guarantee security among MN, BCF, HA, and AAA by bring into a new component BCF to handle security association with MN on behalf of the AAA and multiple home agents during bootstrap procedure. whether the message between MN and BCF should be encrypted or not will be considered in the near future 9. Acknowledgements The authors would like to thank many kindly comments. Deng, Li, Xie, Wang [Page 9]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004 References [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Patel, A. et al. "Problem Statement for bootstrapping Mobile IPv6", draft-ietf-mip6-bootstrap-ps-00 (work in progress), July 2004. [3] Hui Deng, et al. "Load Balance for Distributed Home Agents in Mobile IPv6", draft-deng-mip6-ha-loadbalance-02(work in progress), October 2004. [4] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [5] J. Arkko, et al. "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC3776, June 2004. [6] Manner, J., Kojo, M. "Mobility Related Terminology", RFC 3753, June 2004. [7] G. Giaretta, et al. "MIPv6 Authorization and Configuration based on EAP", draft-giaretta-mip6-authorization-eap-01.txt [8] K. Chowdhury , et al., "RADIUS Attributes for Mobile IPv6 bootstrapping", draft-chowdhury-mip6-bootstrap-radius-00.txt [9] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [10] Patel, A., Leung, K., Akthar, H., Khalil, M. and K. Chowdhury, "Network Access Identifier Option for Mobile IPv6", draft-ietf-mip6-nai-option-00 (work in progress), July 2004. [11] T. Kivinen, "Design of the MOBIKE protocol", draft-ietf-mobike-design-00 (work in progress), June 2004. [12] A. Patel, et al. "Authentication Protocol for Mobile IPv6", draft-ietf-mip6-auth-protocol-00.txt Deng, Li, Xie, Wang [Page 10]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004 Authors' Addresses Hui Deng Research & Development Center Hitachi (China), Investment Ltd. Beijing Fortune Bldg. 1701, 5 Dong San Huan Bei-Lu Chao Yang District, Beijing 100004, China E-mail: hdeng@hitachi.cn Qin Li Department of Computer Science BeiHang University Beijing 100083, China Email: lynch@vmails.net Chongfeng Xie Beijing Research Institute China Telecom Beijing 100035, China Email: xiechf@ctbri.com.cn Minghui Wang Department of Technology China Unicom Beijing 100032, China Email: wangmh@chinaunicom.com.cn Deng, Li, Xie, Wang [Page 11]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004 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 (2004). 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. Deng, Li, Xie, Wang [Page 12]