[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/