MIP6 Working Group V. Devarapalli
Internet-Draft M. Parthasarathy
Expires: September 6, 2006 Nokia
March 5, 2006
Mobile IPv6 Bootstrapping with IKEv1
draft-devarapalli-mip6-ikev1-bootstrap-01.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 September 6, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The current Mobile IPv6 bootstrapping mechanisms require the use of
IKEv2 between the mobile node and the home agent. If the Mobile IPv6
signaling messages are protected by IKEv1 and IPsec as described in
RFC 3776, then the bootstrapping mechanism based on IKEv2 cannot be
used. This document describes a bootstrapping mechanism for Mobile
IPv6 when RFC 3776 is used.
Devarapalli & Parthasarathy Expires September 6, 2006 [Page 1]
Internet-Draft MIP6 Bootstrapping with IKEv1 March 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Home Address Configuration . . . . . . . . . . . . . . . . . . 3
3.1. Using ISAKMP MODECFG . . . . . . . . . . . . . . . . . . . 3
3.2. Using DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Association Setup . . . . . . . . . . . . . . . . . . 4
5. Mobile Node's DNS Entry Update . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Devarapalli & Parthasarathy Expires September 6, 2006 [Page 2]
Internet-Draft MIP6 Bootstrapping with IKEv1 March 2006
1. Introduction
RFC 3775 [2] does not address dynamically configuring a mobile node
with the home agent and home address information. Mobile IPv6
bootstrap mechanisms enable a mobile node to dynamically configure a
home agent, acquire a home address and setup security associations
with the home agent. Such a mechanism is defined in [8]. However,
the bootstrap mechanism defined in [8] uses IKEv2 to configure a home
address and cannot be used if IKEv1 and IPsec as defined in RFC 3776
[3] is used for protecting the Mobile IPv6 signaling messages.
In this document we define a bootstrap mechanism that will work when
RFC 3776 is used. With this mechanism a mobile node will be able to
configure a home address and dynamically setup security associations
with the home agent through IKEv1 [4].
This document does not define a new home agent discovery mechanism.
Home agent discovery based in DNS lookup, as described in [8] should
be used by the mobile node to discover a home agent.
2. 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 [1].
3. Home Address Configuration
3.1. Using ISAKMP MODECFG
The ability to configure an address while setting up an IPsec tunnel
with an VPN gateway is very widely used in the Industry. Many
enterprise networks use VPN gateways that use IKEv1 to setup an IPsec
tunnel with the mobile node and also allocate an address from the
enterprise address space to the mobile node. Any of these mechanisms
can be used by mobile node to configure its home address if it is
using IKEv1 with its home agent to setup security associations for
Mobile IPv6. We describe one such mechanism in this document.
The Home Address can be configured by using the ISAKMP [10]
configuration method described in [6]. When the mobile node
initiates an IKEv1 exchange with the home agent and wants to
configure a home address, it initiates an ISAKMP Transaction exchange
as specified in [6]. The transaction exchange MUST occur after an
ISAKMP phase 1 security association is already established and before
an ISAKMP phase 2 negotiation has started. In the exchange, the
Devarapalli & Parthasarathy Expires September 6, 2006 [Page 3]
Internet-Draft MIP6 Bootstrapping with IKEv1 March 2006
mobile node includes an configuration message of the type
ISAMKP_CFG_REQUEST with the attribute INTERNAL_IP6_ADDRESS. The
address field in the INTERNAL_IP6_ADDRESS attribute should be set to
0::0.
When the home agent sees the request for a home address, it allocates
a home address and returns in the INTERNAL_IP6_ADDRESS attribute in a
ISAKMP_CFG_REPLY message. The home agent can specify the time for
which the home address is valid through the INTERNAL_ADDRESS_EXPIRY
attribute.
The mobile node may also configure additional information from the
home link like a DNS server and a DHCPv6 server by including the
INTERNAL_IP6_DNS and INTERNAL_IP6_DHCP attributes in the
ISAKMP_CFG_REQUEST message.
3.2. Using DHCPv6
The mobile node can run DHCPv6 [9] over the initial IPsec tunnel with
the home agent and configure a home address. RFC 3456 [11] describes
how DHCPv4 can be run over a tunnel between the mobile node and a
security gateway. However, RFC 3456 is only applicable for DHCPv4
and cannot be for Mobile IPv6 home address configuration.
If the home agent supports DHCPv6 relay agent functionality, then the
mobile node can request for a home address over the initial IPsec
tunnel with the home agent. The home agent relays the request from
the mobile node to a DHCPv6 server on the home link. Once the mobile
node acquires a new home address, it should run IKEv1 again to
configure the necessary security associations as required by RFC
3776.
4. Security Association Setup
RFC 3776 describes dynamically setting up security associations
between the mobile node and the home agent using pre-shared secrets
and certificate based mechanisms. If pre-shared secrets or
certificate based mechanisms are the only mechanisms used to
authenticate the mobile node to the home agent, then nothing new
needs to be specified.
If in a particular deployment, the mobile node is authenticated using
mechanisms such as RADIUS, SecureID, mobile node - AAA shared secret
or smart card based authentication mechanism, then RFC 3776 is not
sufficient. The hybrid authentication mechanism as described in [7]
is required. The home agent SHOULD be authenticated using
HybridInitRSA method in the Phase 1 exchange of IKE. This MUST be
Devarapalli & Parthasarathy Expires September 6, 2006 [Page 4]
Internet-Draft MIP6 Bootstrapping with IKEv1 March 2006
immediately followed by the XAUTH exchange described in [5]. The
home agent SHOULD use the Radius CHAP method to authenticate the
mobile node.
5. Mobile Node's DNS Entry Update
If the mobile node has a DNS entry that maps its FQDN to its home
address, the DNS entry becomes invalid if the mobile node bootstraps
a new home address. In order to be reachable at its new home
address, the DNS entry of the mobile node needs to be updated. This
document proposes to use the DNS update mechanism described in
section 6 of [8] to update the mobile node's FQDN with the newly
configured home address.
6. Security Considerations
The transaction exchange for configuring a home address MUST occur
after the ISAKMP phase 1 security association has been setup. This
would enable protecting the entire exchange using the phase 1
security association.
For security considerations regarding the use of IKEv1 for
negotiating security associations between the mobile node and the
home agent using shared keys or certificates, please refer to [3].
For security considerations regarding the use of DNS to discover a
home agent and the use of dynamic DNS updates to update the mobile
node's DNS entry, please refer to [8].
7. IANA Considerations
This document requires no action from IANA.
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Devarapalli & Parthasarathy Expires September 6, 2006 [Page 5]
Internet-Draft MIP6 Bootstrapping with IKEv1 March 2006
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
[4] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[5] Pereira, R., "Extended Authentication within ISAKMP/Oakley",
draft-ietf-ipsec-isakamp-xauth-06 (work in progress), May 1999.
[6] Pereira, R., "The ISAKMP Configuration Method",
draft-ietf-ipsec-isakamp-mode-cfg-05 (work in progress),
August 1999.
[7] Litvin, M., "A Hybrid Authentication mode for IKE",
draft-ietf-ipsec-isakamp-hybrid-auth-05 (work in progress),
August 2000.
[8] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
draft-ietf-mip6-bootstrapping-split-01 (work in progress),
October 2005.
[9] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 3315, July 2003.
8.2. Informative References
[10] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol (ISAKMP)",
RFC 2408, November 1998.
[11] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic Host
Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel
Mode", RFC 3456, January 2003.
Devarapalli & Parthasarathy Expires September 6, 2006 [Page 6]
Internet-Draft MIP6 Bootstrapping with IKEv1 March 2006
Authors' Addresses
Vijay Devarapalli
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043
USA
Email: dvijay@gmail.com
Mohan Parthasarathy
Nokia
313 Fairchild Drive
Mountain View, CA 94043
USA
Email: mohan.parthasarathy@nokia.com
Devarapalli & Parthasarathy Expires September 6, 2006 [Page 7]
Internet-Draft MIP6 Bootstrapping with IKEv1 March 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.
Devarapalli & Parthasarathy Expires September 6, 2006 [Page 8]