MIPv6 bootstrapping solution October 13, 2006 MIP6 working group Saumya Upadhyaya Internet Draft Motorola Document: draft-saumya-mip6-bootstrap-00.txt Expires: April 13, 2007 October 13, 2006 MIPv6 bootstrapping solution for split and integrated scenario using DHCPv6 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 January, 2007. Abstract In mobile IPv6 (MIP6), there is a need to transfer the home agent address, home IP address to the mobile node when the mobile node is in the foreign network. This problem is referred to as bootstrapping. This document defines a Bootstrapping Information Server Function (BISF) and Bootstrapping Information Client Function (BICF). The BICF uses AAA messaging for obtaining the bootstrapping information from the BISF. Such a mechanism can be used by either the integrated or split scenarios. Table of Contents 1. Introduction...................................................2 Saumya Upadhyaya Expires April 13, 2007 [Page 1] MIPv6 bootstrapping solution October 13, 2006 2. Scope of this Document.........................................2 3. Terminology....................................................3 4. Existing solutions.............................................3 5. MIPv6 Bootstrapping solution...................................3 5.1. Solution for integrated scenario..........................3 5.2. Solution for split scenario...............................6 6. DHCP options...................................................8 6.1. BISF Identifier Option....................................8 6.2. MIP Security association option...........................8 7. IANA Considerations...........................................10 8. Security Considerations.......................................10 9. References....................................................10 9.1. Normative References.....................................10 9.2. Informative References...................................10 10. Appendix.....................................................11 10.1. Diameter Messaging......................................11 10.2. Diameter AVPs...........................................12 11. Full Copyright Statement.....................................12 12. Intellectual Property........................................13 1. Introduction The problem statement for bootstrapping is described in [5]. Two mechanisms are currently being discussed in the MIP6 working group to deal with the issue of bootstrapping. [8] discusses the handling of the bootstrapping issue in the split architecture whereas [7] discusses the same for the integrated architecture. This document defines a Bootstrapping Information Server Function (BISF) and Bootstrapping Information Client Function (BICF). The BISF is a network entity which stores the generated security association. In the integrated scenario, this could be at the NAS or AAAF whereas in the split scenario, this could be at the MSA. The BICF uses a AAA messaging for obtaining the bootstrapping information from the BISF. Appendix of this draft illustrates one such Diameter[4] messaging. Such a mechanism can be used by either the integrated or split scenarios. 2. Scope of this Document This document describes a solution for the MIPv6 bootstrapping problem described in [5] using DHCPv6 [1] for both the split scenario as well as the integrated scenario. Saumya Upadhyaya Expires April 13, 2007 [Page 2] MIPv6 bootstrapping solution October 13, 2006 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. MIP6 Bootstrapping This includes the parameters that are required parameters for MIP6 bootstrapping like the home address of the mobile, the home agent address, home prefix and optionally, the mobile security associations. Bootstrapping The BISF is a network entity which stores Information Server bootstrapping information (eg., NAS, AAAF, Function (BISF) AAAH) Bootstrapping The BICF is a network entity which acquires Information Client the bootstrapping information from the BISF Function (BICF) and transfers the same to the client (eg., DHCP Server) 4. Existing solutions [7] discusses a solution for bootstrapping for the integrated architecture. In this solution, the NAS is fixed as a DHCP relay and adds the bootstrapping information obtained during layer 2 authentication to the DHCP message towards the DHCP server. Adding functionality in the relays will require changes in existing relays. Also, the DHCP server behavior will need to be modified to transfer the bootstrapping information received from the relay back to the mobile node. [8] discusses a solution for bootstrapping for the split scenario. In this solution, mobile node needs to have the home agent name configured. DNS is used to obtain the home agent IP address using which the mobile node contacts the HA with extensions defined in [9]. This draft defines a common method for bootstrapping of MIPv6 parameters in both the split and integrated architectures. The BISF name/domain is given by the mobile node and the DHCP Server uses this to obtain the bootstrapping information. In the integrated scenario, the BISF is local (say, NAS) and in the split scenario, the BISF is remote (MSA). 5. MIPv6 Bootstrapping solution 5.1. Solution for integrated scenario Saumya Upadhyaya Expires April 13, 2007 [Page 3] MIPv6 bootstrapping solution October 13, 2006 In the integrated scenario, the access service authorizer and the mobility service authorizer are the same. The architecture for the integrated scenario is shown in Fig 1. ASP(/MSP) | ASA/MSA(/MSP) | | +-------+ | +-------+ | | | | | |AAAV |-----------|--------|AAAH | | | | | | | | | | | +-------+ | +-------+ | | | | | --------| | | | | | | +-----+ | | | +----+ | | | | | | MN |------| NAS | | | | +----+ | | | | | | +-----+ | | | | +------+ | | | |DHCP | | | |--------------------|Server| | | | | | | +------+ | | | | | +--------+ | | HA | | |in MSP | | +--------+ Fig. 1: Network diagram for integrated scenario Figure 2 shows the sequence of steps to obtain the MIPv6 bootstrapping parameters in the integrated scenario. 1. The mobile node performs the access authorization procedure. The figure shows a EAP as an example of authorization protocol. 2. Since the L2 authentication is between the MN and AAAH, the NAS encapsulates the EAP packet in a Diameter message and transfers it to the AAAH. The AAAH authenticates the MN and authorizes it for the MIPv6 service. If the MN is authorized for MIPv6, the AAAH transfers the bootstrapping parameters to the NAS via Diameter [7]. 3. After L2 authentication is complete, the MN initiates DHCPv6 Information request to obtain the MIPv6 bootstrapping parameters Saumya Upadhyaya Expires April 13, 2007 [Page 4] MIPv6 bootstrapping solution October 13, 2006 in addition to other DHCP configuration parameters, if any. The DHCP client will send this message to the All_DHCP_Relay_Agents_and_Servers multicast address. It also includes the client’s Mobile IP Identity (say, the NAI [2]) in the message. The client MUST include the BISF Identifier option containing the identity of the BISF providing service. This option is defined in section 6.1. 4. The DHCP server contacts the BISF (in this case, NAS in the visited network) to obtain the MIPv6 bootstrapping parameters using the AAA messaging 5. The DHCP server sends the obtained bootstrapping parameters to the MN in the Home Network Information Option [6] and/or the MIP Security association option (see section 6.2) of the DHCPREPLY. +----+ +------+ +-------+ +-----+ +-----+ | | |BISF | |BICF | | | | | | MN/| |(NAS | |(DHCP | |AAAH | | HA | |User| |/AAAF)| |Server)| | | | | | | | | | | | | | | +----+ +------+ +-------+ +-----+ +-----+ | | | | | | 1 EAP | 2 EAP over Diameter | | |<------------->|<---------------------->| | | | | | | | | | | | | 3 DHCPINFREQ | | | | |---------------------------->| | | | | | | | | | 4 Fetch Data| | | | |<----------->| | | | | Request/Reply | | | | | | | | 5 DHCPREPLY | | | | |<----------------------------| | | | | | | | | | 6 BU | | | |------------------------------------------------>| | | | | | | | | |7 AAA Request/Answer | | | |<------>| | | | | | | | 8 BA | | | |<------------------------------------------------| Fig. 2: Integrated scenario call flow The above description assumes the mobile node using stateless auto- configuration for IP address acquisition and uses DHCP only to obtain configuration parameters. This mechanism can be applied to the stateful configuration case also. Saumya Upadhyaya Expires April 13, 2007 [Page 5] MIPv6 bootstrapping solution October 13, 2006 5.2. Solution for split scenario In the split scenario, the access service authorizer and the mobility service authorizer are different. The mobile node sends the MSA name or MSA realm to the DHCP server in the BISF identifier option while requesting bootstrapping parameters. The DHCP Server uses the AAA messaging to transfer the information from the BISF (in this case, the MSA). The architecture for the split scenario is shown in Fig 3. MSP | MSA(/MSP) | | +-------+ | +-------+ | | | | | |AAAV |-----------|--------|AAAH | | | | | | | | | | | +-------+ | +-------+ | | | | | | | | | | | | | --------| | | | | | | +-----+ | | | +----+ | | | | | | MN |------| NAS | | | | +----+ | | | | | | +-----+ | | | | +------+ | | | |DHCP | | | |--------------------|Server| | | | | | | +------+ | | | | | +--------+ | | HA | | |in MSP | | +--------+ Fig. 3: Network diagram for split scenario Saumya Upadhyaya Expires April 13, 2007 [Page 6] MIPv6 bootstrapping solution October 13, 2006 +----+ +-------+ +-----+ +-----+ | | | BICF | |BISF | | | | MN/| |(DHCP | |(AAAH| | HA | |User| |Server)| |/MSA)| |(MSP)| | | | | | | | | +----+ +-------+ +-----+ +-----+ | | | | | | | | | 1 DHCPINFREQ | | | |-------------->| | | | | | | | |2 Fetch Data | | |<-------->| | | | Request/Reply | | | | | | 3 DHCPREPLY | | | |<--------------| | | | | | | | 4 BU | | | |---------------------------------->| | | | | | | |5 AAA Request/Answer | | |<------>| | | | | | 6 BA | | | |<----------------------------------| | | | | | | | | Fig. 4: split scenario call flow Figure 4 shows the sequence of steps to obtain the MIPv6 bootstrapping parameters in the split scenario. 1. After the mobile node completes the L2 authentication with the ASA, the mobile node initiates DHCP to obtain configuration parameters which may include the bootstrapping parameters. The mobile node SHOULD include the BISF identification option (eg: MSA domain) in the DHCPv6 Information Request. 2. The DHCP server contacts the BISF (in this case, the MSA) to obtain the configuration parameters which may include the bootstrapping parameters. 3. The DHCP server sends the obtained bootstrapping parameters to the MN in the DHCPREPLY 4. The MN uses the bootstrapping information received in the DHCPREPLY to send a Binding Update to the HA. Saumya Upadhyaya Expires April 13, 2007 [Page 7] MIPv6 bootstrapping solution October 13, 2006 5. If the BU contains the authentication extensions and HA does not have the security associations, the HA uses mechanisms described in [10] to obtain the security associations from the AAA. 6. The HA sends a BA to the MN after authorization. 6. DHCP options 6.1. BISF Identifier Option This option is used by the client to inform the DHCP Server of the BISF which will provide the bootstrapping information. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_BISFID | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BISF Identity... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig 5: BISF Identifier option option-code OPTION_BISFID (TBD) option-len 4 + length of BISF Identity NAS Identity Provides the identity of the BISF 6.2. MIP Security association option When the DHCP client requests for establishment of a MIP SA, it includes the option code of the MIP Security Association Option in the option request option. The DHCP server obtains the requested information from the BISF using AAA messaging. On obtaining the MIP SA from the BISF, the DHCP server provides the MIP SA to the DHCP client in the option defined below 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_MIPKEYGEN | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Generation Data.. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig 6: MIP Security Association Option option-code OPTION_MIPKEYGEN (TBD) Saumya Upadhyaya Expires April 13, 2007 [Page 8] MIPv6 bootstrapping solution October 13, 2006 option-len 4 + length of key generation data field/s Key Generation Data The MIPv6 Security association which consists of the nonce and other information required by the MIP client to create the keys. The contents of the key generation data are described below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SA Type | SA Length | Algorithm Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AAA SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Generation Nonce ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig 7: key generation data in key generation option SA Type 0 – MN-HA 1 – MN-FA SA Length Length of the key generation data excluding the SA type And SA length SPI MN-HA SPI if SA Type is 0 MN-FA SPI if SA Type is 1 lifetime This field indicates the duration of time (in seconds) for which the keying material used to create the authentication key is valid. AAA SPI A 32-bit opaque value, indicating the SPI that the client must use to determine the transform to use for establishing the Security Association between the client and the HA/FA. Algorithm Identifier This field indicates the transform to be used (stored as part of the Security Association) with the Saumya Upadhyaya Expires April 13, 2007 [Page 9] MIPv6 bootstrapping solution October 13, 2006 HA/FA. Key Generation Nonce A random [6] value of at least 128 bits. The MIP Security association option can have at least one and at most two key generation data fields. The algorithm which is used to compute the authentication information is out of scope of this document. The transfer of the MIP security association to the MIP stack is out of scope of this document. 7. IANA Considerations Value of OPTION_MIPKEYGEN is TBD Value of OPTION_BISFID is TBD 8. Security Considerations 9. References 9.1. Normative References [1] R. Droms (ed.), J. Bound, B. Volz, T. Lemon, C. Perkins, and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003 [2] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [5] Patel, Ed & Giaretta, Ed, "Problem Statement for bootstrapping Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05, May 26, 2006 [6] Jang, et al., "DHCP Option for Home Information Discovery in MIPv6", draft-jang-mip6-hiopt-00.txt, June 8, 2006 [7] Chowdhury, Editor & Yegin., "MIP6-bootstrapping via DHCPv6 for the Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-01, June 9, 2006 [8] Bournelle (Ed.), et al., "Mobile IPv6 Bootstrapping using Diameter in the Split Scenario", draft-ietf-dime-mip6-split-00, June 19, 2006 [9] Patel, et al., "Authentication Protocol for Mobile IPv6", RFC 4285, Jan 2006 9.2. Informative References [10] Vihang Gangaram, "HA-AAA Diameter interface for MIP6", Work in progress Saumya Upadhyaya Expires April 13, 2007 [Page 10] MIPv6 bootstrapping solution October 13, 2006 10. Appendix This section defines the Diameter specification for obtaining the bootstrapping parameters. This section is informational only. 10.1. Diameter Messaging 10.1.1. Fetch-Data-Request (FDR) Command The Fetch-Data-Request (FDR) command is indicated by the Command-Code set to TBD and the Command Flags ’R’ bit set. The BICF sends this message to the BISF to obtain the bootstrapping information indicated by Data-Request-Code AVP. The ABNF of the FDR message is given below: ::= < Diameter Header: xxx, REQ, PXY > < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } [ Destination-Host ] [ User-Name ] { Data-Request-Code } 1 * { Data-Request-Format } * [ Proxy-Info ] * [ Route-Record ] * [ AVP ] 10.1.2. Fetch-Data-Answer (FDA) Command The Fetch-Data-Answer (FDA) is indicated by the Command-Code set to TBD and the Command Flags ’R’ bit cleared. The BISF sends this message in response to a previously received FDR message. The ABNF of the FDA command is given below: ::= < Diameter Header: xxx, PXY > < Session-Id > { Result-Code } { Origin-Host } { Origin-Realm } [ User-Name ] [ Data-Requested ] [ Data-Request-Format ] * [ Proxy-Info ] * [ Route-Record ] * [ AVP ] Saumya Upadhyaya Expires April 13, 2007 [Page 11] MIPv6 bootstrapping solution October 13, 2006 10.2. Diameter AVPs This draft introduces the following new AVPs 10.2.1. Data-Request-Code AVP The Data-Request-Code AVP (AVP Code TBD) is of type enum and indicates the data requested by the client. The list of possible values is to be defined. 10.2.2. Data-Request-Format AVP The Data-Request-Format AVP (AVP Code TBD) is of type enum and indicates the possible format of the requested/received data. The list of possible values is to be defined. 10.2.3. Data-Requested AVP The Data-Requested AVP (AVP Code TBD) is of type OctetString and contains the bootstrapping information in the format specified in Data-Request-Format AVP. Authors' Addresses Saumya Upadhyaya Motorola 66/1, Bagmane Tech Park, C V Raman Nagar, Bangalore, 560093 saumya@motorola.com Contributors Significant contributions were made by Nikhil Suares, Satendra G, Vishnu Ram, Nitin Jain, Vihang Kamble and Liyaqatali G Nadaf. 11. Full 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. 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, Saumya Upadhyaya Expires April 13, 2007 [Page 12] MIPv6 bootstrapping solution October 13, 2006 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. 12. Intellectual Property 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. Saumya Upadhyaya Expires April 13, 2007 [Page 13]