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

Versions: 00 01 02 03 04 05 06 07 08 RFC 4877

MIP6 Working Group                                        V. Devarapalli
Internet-Draft                                                     Nokia
Expires: August 24, 2005                               February 20, 2005


  Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture
                   draft-ietf-mip6-ikev2-ipsec-01.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  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 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.

   This Internet-Draft will expire on August 24, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes Mobile IPv6 operation with the revised IPsec
   architecture and IKEv2.








Devarapalli              Expires August 24, 2005                [Page 1]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  What is applicable from RFC 3776?  . . . . . . . . . . . . . .  5
     3.1   Packet Formats . . . . . . . . . . . . . . . . . . . . . .  5
     3.2   Requirements . . . . . . . . . . . . . . . . . . . . . . .  5
       3.2.1   Home Agent Requirements  . . . . . . . . . . . . . . .  5
       3.2.2   Mobile Node Requirements . . . . . . . . . . . . . . .  6
   4.  Manual Configuration . . . . . . . . . . . . . . . . . . . . .  7
     4.1   Binding Update and Acknowledgements  . . . . . . . . . . .  7
     4.2   Return Routabililty Messages . . . . . . . . . . . . . . .  8
     4.3   Mobile Prefix Discovery Messages . . . . . . . . . . . . .  9
     4.4   Payload Packets  . . . . . . . . . . . . . . . . . . . . . 10
   5.  Dynamic Configuration  . . . . . . . . . . . . . . . . . . . . 11
     5.1   Security Policy Database Entries . . . . . . . . . . . . . 11
       5.1.1   Binding Updates and Acknowledgements . . . . . . . . . 11
       5.1.2   Return Routability Messages  . . . . . . . . . . . . . 12
       5.1.3   Mobile Prefix Discovery Messages . . . . . . . . . . . 13
       5.1.4   Payload Packets  . . . . . . . . . . . . . . . . . . . 13
     5.2   Security Association negotiation using IKEv2 . . . . . . . 14
   6.  The use of EAP authentication  . . . . . . . . . . . . . . . . 17
   7.  Dynamic Home Address Configuration . . . . . . . . . . . . . . 19
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   10.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 24
     11.1  Normative References . . . . . . . . . . . . . . . . . . . 24
     11.2  Informative References . . . . . . . . . . . . . . . . . . 24
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 25
       Intellectual Property and Copyright Statements . . . . . . . . 26




















Devarapalli              Expires August 24, 2005                [Page 2]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


1.  Introduction

   RFC 3776 describes how IPsec [11] is used with Mobile IPv6 [2] to
   protect the signaling messages.  It also illustrates examples of
   Security Policy Database and Security Association Database entries
   that can be used to protect Mobile IPv6 signaling messages.

   The IPsec architecture has been revised [5].  Among the many changes,
   the list of selectors has been expanded to included the Mobility
   Header message type.  This has an impact on how security policies and
   security associations are configured for protecting mobility header
   messages.  It becomes easier to differentiate between the various
   Mobility Header messages based on the type value instead of checking
   if a particular mobility header message is being sent on a tunnel
   interface between the mobile node and the home agent, as it was in
   RFC 3776.  The revised IPsec architecture specification also includes
   ICMP message type and code as selectors.  This makes it possible to
   protect Mobile Prefix Discovery messages without applying the same
   security associations to all ICMPv6 messages.

   This document discusses new requirements for the Home Agent and the
   mobile node to use the revised IPsec architecture and IKEv2.
   Section 3.2 lists the requirements.  Section 3 describes the
   differences with RFC 3776.  Section 4 describes the required Security
   Policy Database (SPD) and Security Association Database (SAD)
   entries.

   The Internet Key Exchange (IKE) has also been substantially revised
   and simplified [4].  This document describes how IKEv2 can be used to
   setup security associations for Mobile IPv6.

   The use of EAP within IKEv2 is allowed to authenticate the mobile
   node to the Home Agent.  This is described in Section 6.  A method
   for dynamically configuring a home address from the Home Agent using
   the Configuration Payload in IKEv2 is described in Section 7.
















Devarapalli              Expires August 24, 2005                [Page 3]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


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].














































Devarapalli              Expires August 24, 2005                [Page 4]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


3.  What is applicable from RFC 3776?

3.1  Packet Formats

   The mobile node and the Home Agent must support the packet formats as
   defined in Section 3 of RFC 3776.  This document does not update the
   packet formats described in RFC 3776.

3.2  Requirements

   The mobile node and the Home Agent MUST support the requirements
   listed in Section 4 of RFC 3776 with the following exceptions.

   o  It is not required to configure security policies per interface in
      order to protect return routability signaling messages.  Since the
      Mobility Header message type is a selector, it is easy to
      differentiate HoTi and HoT messages from other Mobility Header
      messages.

   o  It is necessary to avoid a condition where a mobile node could use
      its security association to send a Binding Update on behalf of
      another mobile node.  With manual IPsec configuration, the Home
      Agent MUST be able to verify that a security association was
      created for a particular home address.  With dynamic keying, it
      should be possible for the Home Agent to verify that the identity
      presented in the IKE_AUTH exchange is allowed to create security
      associations for a particular home address.

   o  The mobile node should use its Care-of Address as source address
      in protocol exchanges, when using dynamic keying.  However, the
      security associations MUST be created for the home address of the
      mobile node.

   o  The mobile node and the Home Agent MUST create security
      associations based on the home address, so that the security
      associations survive change in Care-of Address.  When using IKEv2
      as the key exchange protocol, the home address should be carried
      in the TSi payload during the CREATE_CHILD_SA exchange [4].


3.2.1  Home Agent Requirements

   This section describes additional requirements on the Home Agent.

   o  The Home Agent MUST support Mobility Header message type as an
      IPsec selector.





Devarapalli              Expires August 24, 2005                [Page 5]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


   o  The Home Agent MUST support ICMPv6 message type as an IPsec
      selector.

   o  The Home Agent MUST be able to distinguish between HoTi messages
      sent to itself, when it is acting as a Correspondent Node, from
      those sent to Correspondent Nodes when it is acting as a Home
      Agent, based on the destination address of the packet.

   o  The Home Agent MAY use the Peer Authorization Database (PAD) [5]
      to store per-mobile node state.  The PAD entry for a mobile node
      can contain a shared key, public key or a trust anchor to verify
      the mobile node's certificate for authenticating the mobile node.

   o  The Home Agent MAY support remote configuration of home address as
      described in Section 7.  When the Home Agent receives a
      configuration payload with a CFG_REQUEST for INTERNAL_IP6_ADDR, it
      must reply with a valid home address for the mobile node.  The
      Home Agent could pick a home address from a local database or from
      a DHCPv6 server on the home link.

   o  The Home Agent MAY support authentication using EAP in IKEv2 as
      described in Section 2.16 of [4].


3.2.2  Mobile Node Requirements

   This section describes additional requirements on the mobile node.

   o  The mobile node MUST support Mobility Header message type as an
      IPsec selector.

   o  The mobile node MUST support ICMPv6 message type as an IPsec
      selector.

   o  The mobile node MAY support EAP as an authentication mechanism
      when using IKEv2 to setup security associations for protecting
      Mobile IPv6 signaling messages.

   o  The mobile node MAY support the mechanism described in Section 7
      to dynamically configure a home address.











Devarapalli              Expires August 24, 2005                [Page 6]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


4.  Manual Configuration

   This section describes the SPD and SAD entries that can be used to
   protect Mobile IPv6 signaling messages.

   For the examples described in this document, a mobile node with home
   address, "home_address_1", a Home Agent with address, "home_agent_1"
   and a user of the mobile node with identity "user_1" are assumed.  If
   the home address of the mobile node changes, the SPD and SAD entries
   need to re-created or updated for the new home address.

4.1  Binding Update and Acknowledgements

   The following are the SPD and SAD entries on the mobile node and the
   Home Agent to protect Binding Updates and Acknowledgements.




































Devarapalli              Expires August 24, 2005                [Page 7]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


        mobile node SPD-S:
          - IF source = home_address_1 & destination = home_agent_1 &
               proto = MH & mh_type = BU
            Then use SA SA1

        mobile node SPD-I:
          - IF source = home_agent_1 & destination = home_address_1 &
               proto = MH & mh_type = BAck
            Then use SA SA2

        mobile node SAD:
          - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT):
            source = home_address_1 & destination = home_agent_1 &
            proto = MH & mh_type = BU
          - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT):
            source = home_agent_1 & destination = home_address_1 &
            proto = MH & mh_type = BAck

        home agent SPD-S:
          - IF source = home_agent_1 & destination = home_address_1 &
               proto = MH & mh_type = BAck
            Then use SA SA2

        home agent SPD-I:
          - IF source = home_address_1 & destination = home_agent_1 &
               proto = MH & mh_type = BU
            Then use SA SA1

        home agent SAD:
          - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT):
            source = home_agent_1 & destination = home_address_1 &
            proto = MH & mh_type = BAck
          - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT):
            source = home_address_1 & destination = home_agent_1 &
            proto = MH & mh_type = BU


4.2  Return Routabililty Messages

   The following are the SPD and SAD entries on the mobile node and the
   Home Agent to protect Return Routability messages.










Devarapalli              Expires August 24, 2005                [Page 8]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


        mobile node SPD-S:
          - IF source = home_address_1 & destination = any &
            proto = MH & mh_type = HoTi
            Then use SA SA3

        mobile node SPD-I:
          - IF destination = home_address_1 & source = any &
            proto = MH & mh_type = HoT
            Then use SA SA4

        mobile node SAD:
          - SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL):
            source = home_address_1 & destination = any & proto = MH &
            mh_type = HoTi
          - SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL):
            source = any & destination = home_address_1 & proto = MH &
            mh_type = HoT

        home agent SPD-S:
          - IF destination = home_address_1 & source = any &
            proto = MH & mh_type = HoT
            Then use SA SA4

        home agent SPD-I:
          - IF source = home_address_1 & destination = any &
            proto = MH & mh_type = HoTi
            Then use SA SA3

        home agent SAD:
          - SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL):
            source = any & destination = home_address_1 & proto = MH &
            mh_type = HoT
          - SA3(IN, spi_c, home_agent_1, ESP, TUNNEL):
            source = home_address_1 & destination = any & proto = MH &
            mh_type = HoTi


4.3  Mobile Prefix Discovery Messages

   The following are the SPD and SAD entries used to protect Mobile
   Prefix Discovery messages.










Devarapalli              Expires August 24, 2005                [Page 9]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


        mobile node SPD-S:
          - IF source = home_address_1 & destination = home_agent_1 &
               proto = ICMPv6 & icmp6_type = MPS
            Then use SA SA5.

        mobile node SPD-I:
          - IF source = home_agent_1 & destination = home_address_1 &
               proto = ICMPv6 & icmp6_type = MPA
            Then use SA SA6

        mobile node SAD:
          - SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT):
            source = home_address_1 & destination = home_agent_1 &
            proto = ICMPv6 & icmp6_type = MPS
          - SA6(IN, spi_f, home_address_1, ESP, TRANSPORT):
            source = home_agent_1 & destination = home_address_1 &
            proto = ICMPv6 & icmp6_type = MPA

        home agent SPD-S:
          - IF source = home_agent_1 & destination = home_address_1 &
               proto = ICMPv6 & icmp6_type = MPA
            Then use SA SA6

        home agent SPD-I:
          - IF source = home_address_1 & destination = home_agent_1 &
               proto = ICMPv6 & icmp6_type = MPS
            Then use SA SA5

        home agent SAD:
          - SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT):
            source = home_agent_1 & destination = home_address_1 &
            proto = ICMPv6 & icmp6_type = MPA
          - SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT):
            source = home_address_1 & destination = home_agent_1 &
            proto = ICMPv6 & icmp6_type = MPS


4.4  Payload Packets

   Payload traffic tunneled through the Home Agent can be protected by
   IPsec, if required.  The mobile node and the Home Agent use ESP in
   tunnel mode to protect the tunneled traffic.  The SPD and SAD entries
   shown in Section 5.2.4 of [3] are applicable here.








Devarapalli              Expires August 24, 2005               [Page 10]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


5.  Dynamic Configuration

   This section describes the use of IKEv2 to setup the required
   security associations.

5.1  Security Policy Database Entries

   The following sections describe the security policy entries on the
   mobile node and the Home Agent.  In the examples shown below, the
   identity of the user of the mobile node is assumed to be user_1, the
   home address of the mobile node is assumed to be home_address_1 and
   the IPv6 address of the Home Agent is assumed to be home_agent_1.

5.1.1  Binding Updates and Acknowledgements

   The following are the SPD entries on the mobile node and the Home
   Agent for protecting Binding Updates and Acknowledgements.

        mobile node SPD-S:
          - IF destination = home_agent_1 & proto = MH & mh_type = BU
            Then use SA ESP transport mode
                            IDi = user_1, IDr = home_agent_1,
                            TSi = home_address_1

        mobile node SPD-I:
          - IF source = home_agent_1 & proto = MH & mh_type = BAck
            Then use SA ESP transport mode
                            IDi = user_1, IDr = home_agent_1,
                            TSi = home_address_1

        home agent SPD-S:
          - IF source = home_agent_1 & proto = MH & mh_type = BAck
            Then use SA ESP transport mode
                            IDr = user_1, IDi = home_agent_1,
                            TSr = home_address_1

        home agent SPD-I:
          - IF destination = home_agent_1 & proto = MH & mh_type = BU
            Then use SA ESP transport mode
                            IDr = user_1, IDi = home_agent_1,
                            TSr = home_address_1

   In the examples shown above, the home address of the mobile node
   might not be available all the time.  When the mobile node acquires a
   new home address, it must add the address to the corresponding SPD
   entries.

   The Mobility Header type is negotiated by placing it in the most



Devarapalli              Expires August 24, 2005               [Page 11]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


   significant eight bits of the 16 bit local "port" selector during
   IKEv2 exchange.  For more details, refer to [5].  The TSi and TSr
   payloads in the above examples will contain many other selectors
   apart from home_address_1.  For the sake of brevity, they are not
   shown here.

5.1.2  Return Routability Messages

   The following are the SPD entries on the mobile node and the Home
   Agent for protecting the Return Routability messages.

        mobile node SPD-S:
          - IF proto = MH & mh_type = HoTi
            Then use SA ESP tunnel mode
                            IDi = user_1,
                            outer src addr = coa
                            outer dst addr = home_agent_1,
                            inner src addr = home_address_1

        mobile node SPD-I:
          - IF destination = home_address_1 & proto = MH & mh_type = HoT
            Then use SA ESP tunnel mode
                            IDi = user_1,
                            outer src addr = home_agent_1,
                            outer dst addr = coa,

        home agent SPD-S:
          - IF proto = MH & mh_type = HoT
            Then use SA ESP tunnel mode
                            IDr = user_1,
                            outer src addr = home_agent_1,
                            outer dst addr = coa,
                            inner dst addr = home_address_1

        home agent SPD-I:
          - IF proto = MH & mh_type = HoTi
            Then use SA ESP tunnel mode
                            IDr = user_1,
                            outer src addr = coa,
                            outer dst addr = home_agent_1,
                            inner src addr = home_address_1

   When the mobile node's Care-of Address changes the SPD entries on
   both the mobile node and the Home Agent must be updated.  The Home
   Agent knows about the change in Care-of Address of the mobile node
   when it receives a Binding Update from the mobile node.





Devarapalli              Expires August 24, 2005               [Page 12]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


5.1.3  Mobile Prefix Discovery Messages

   The following are the SPD entries on the mobile node and the Home
   Agent for protecting Mobile Prefix Discovery messages.

        mobile node SPD-S:
          - IF destination = home_agent_1 & proto = ICMPv6 &
               icmp6_type = MPS
            Then use SA ESP transport mode
                            IDi = user_1, IDr = home_agent_1,
                            TSi = home_address_1
        mobile node SPD-I:
          - IF source = home_agent_1 & proto = ICMPv6 & icmp6_type = MPA
            Then use SA ESP transport mode
                            IDi = user_1, IDr = home_agent_1,
                            TSi = home_address_1

        home agent SPD-S:
          - IF source = home_agent_1 & proto = ICMPv6 & icmp6_type = MPA
            Then use SA ESP transport mode
                            IDr = user_1, IDi = home_agent_1,
                            TSr = home_address_1

        home agent SPD-I:
          - IF destination = home_agent_1 & proto = ICMPv6 &
               icmp6_type = MPS
            Then use SA ESP transport mode
                            IDr = user_1, IDi = home_agent_1,
                            TSr = home_address_1

   In the examples shown above, the home address of the mobile node
   might not be available all the time.  When the mobile node acquires a
   new home address, it must add the address to the corresponding SPD
   entries.

   The TSi and TSr payloads in the above examples will contain many
   other selectors apart from home_address_1.  For brevity, they are not
   show here.

5.1.4  Payload Packets

   The following are the SPD entries on the mobile node and the Home
   Agent if payload traffic exchanged between the mobile node and its
   Correspondent Node needs to be protected.  The SPD entries are
   similar to the entries for protecting Return Routability messages and
   have lower priority than the above SPD entries.





Devarapalli              Expires August 24, 2005               [Page 13]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


        mobile node SPD-S:
          - IF interface = IPv6 tunnel to home_agent_1 &
               proto = X
            Then use SA ESP tunnel mode
                            IDi = user_1,
                            outer src addr = coa
                            outer dst addr = home_agent_1,
                            inner src addr = home_address_1

        mobile node SPD-I:
          - IF destination = home_address_1 & proto = X &
               source = any_cn
            Then use SA ESP tunnel mode
                            IDi = user_1,
                            outer src addr = home_agent_1,
                            outer dst addr = coa,

        home agent SPD-S:
          - IF interface = IPv6 tunnel to home_address_1 &
               proto = X
            Then use SA ESP tunnel mode
                            IDr = user_1,
                            outer src addr = home_agent_1,
                            outer dst addr = coa,
                            inner dst addr = home_address_1

        home agent SPD-I:
          - IF interface = IPv6 tunnel to home_address_1 &
               proto = X
            Then use SA ESP tunnel mode
                            IDr = user_1,
                            outer src addr = coa,
                            outer dst addr = home_agent_1,
                            inner src addr = home_address_1


5.2  Security Association negotiation using IKEv2

   Mobile IPv6 signaling messages are typically initiated by the mobile
   node.  The mobile node sends a Binding Update to the Home Agent
   whenever it moves and acquires a new Care-of Address.

   The mobile node initiates an IKEv2 protocol exchange if the required
   security associations are not present.  The default mechanism used
   for mutual authentication is a shared secret between the mobile node
   and the Home Agent.  The Home Agent uses the identity of the mobile
   node to identify the corresponding shared secret.  If public key
   based mechanism is used, the Home Agent and the mobile node use their



Devarapalli              Expires August 24, 2005               [Page 14]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


   private keys to generate the AUTH payload.  The mobile node and the
   Home Agent should use CERTREQ and CERT payloads if the identities
   need to be verified.  If the mobile node is configured with the Home
   Agent information including the public key that corresponds to the
   Home Agent, then the mobile node MAY exclude the CERTREQ payload in
   message 3.  Similarly, the Home Agent MAY exclude the CERTREQ payload
   in message 2, if it is configured with the mobile node information.

   If a shared secret is being used, the mobile node uses the shared
   secret to generate the AUTH payload in the IKE_AUTH exchange.  If the
   mobile node is using a public key based mechanism, then it uses its
   private key to generate the AUTH payload in the IKE_AUTH exchange.

        Mobile Node                      Home Agent
        -----------                      ----------
        HDR, SAi1, KEi, Ni      -->

                               <--      HDR, SAr1, KEr, Nr, [CERTREQ]

        HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
                 AUTH, SAi2, TSi, TSr}
                                -->

                               <--      HDR, SK {IDr, [CERT,] AUTH,
                                                  SAr2, TSi, TSr}

   The mobile node MUST always includes its identity in the IDi payload
   in the IKE_AUTH exchange.  The mobile node could use the following
   different types of identities to identity itself to the Home Agent.

   o  Home Address - The mobile node could use its statically configured
      home address as its identity.  In this case the ID Type field is
      set to ID_IPV6_ADDR.
   o  FQDN - The mobile node can use a Fully Qualified Domain Name as
      the identifier and set the ID Type field to ID_FQDN.
   o  RFC 822 identifier - If the mobile node uses a RFC 822 identifier
      [9], it sets the ID Type field to ID_RFC822_ADDR.

   After the IKE_AUTH exchange completes, the mobile node and the Home
   Agent initiate CREATE_CHILD_SA exchanges to negotiate security
   associations for protecting Binding Update/Binding Ack messages,
   Return Routability signaling, Mobile Prefix Discovery messages and
   optionally payload traffic.  The CREATE_CHILD_SA exchanges are
   protected by the security association created during the IKE_AUTH
   exchange.

   It is important that the security associations are created based on
   the home address of the mobile node, so that the security



Devarapalli              Expires August 24, 2005               [Page 15]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


   associations survive Care-of Address change.  The mobile node MUST
   set the TSi (Traffic Selector-initiator) payload to its home address
   in the CREATE_CHILD_SA exchange in order to create the security
   associations for the home address.

        Mobile Node                      Home Agent
        -----------                      ----------
        HDR, SK {[N], SA, Ni, [KEi],
                 [TSi, TSr]}    -->

                                <--      HDR, SK {SA, Nr, [KEr],
                                                  [TSi, TSr]}







































Devarapalli              Expires August 24, 2005               [Page 16]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


6.  The use of EAP authentication

   In addition to using public key signatures and shared secrets, EAP
   [10] can be used with IKEv2 for authenticating the mobile node to the
   Home Agent.

   The mobile node indicates that it wants to use EAP by including the
   IDi payload but leaving out the AUTH payload in the first message
   during the IKE_AUTH exchange.  The Home Agent then includes an EAP
   payload if it is willing to use an extensible authentication method.
   Security associations are not created until the subsequent IKE_AUTH
   exchange after successful EAP authentication.  The use of EAP adds at
   least two round trips to the IKE negotiation.

        Mobile Node                     Home Agent
        ------------                    ----------
        HDR, SAi1, KEi, Ni      -->

                                <--     HDR, SAr1, KEr, Nr, [CERTREQ]

        HDR, SK {IDi, [CERTREQ,] [IDr,]
                 SAi2, TSi, TSr}-->

                                <--     HDR, SK {IDr, [CERT,] AUTH,
                                                 EAP }

        HDR, SK {EAP}           -->

                                <--     HDR, SK {EAP (success)}

        HDR, SK {AUTH}          -->

                                <--     HDR, SK {AUTH, SAr2, TSi,
                                                 TSr}

   Some EAP methods generate a shared key on the mobile node and the
   Home Agent once the EAP authentication succeeds.  In this case, the
   shared key is used to generate the AUTH payloads in the subsequent
   messages.  The shared key, if used to generate the AUTH payloads,
   MUST NOT be used for any other purpose.  For more details, refer to
   [4].

   The use of EAP between the mobile node and the Home Agent might
   require the Home Agent to contact an authorization server like the
   AAA Home server, on the home link, to authenticate the mobile node.
   Please refer to [7] for more details.

   The IKEv2 specification [4] requires that public key based mechanism



Devarapalli              Expires August 24, 2005               [Page 17]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


   be used to authenticate the Home Agent to the mobile node, when EAP
   is used.  But, if the EAP method that is used, supports mutual
   authentication and and key generation, then the mobile node could use
   EAP itself to authenticate the Home Agent.  The mobile node can
   request that the Home Agent also use EAP to authenticate itself, by
   including the EAP_ONLY_AUTHENTICATION notification payload [8] in
   message 3.  If the Home Agent agrees to use EAP, it omits the public
   key based AUTH and CERT payloads in message 4.  More details can be
   found in [8].










































Devarapalli              Expires August 24, 2005               [Page 18]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


7.  Dynamic Home Address Configuration

   The mobile node can dynamically configure a home address by including
   a Configuration Payload in the IKE_AUTH exchange, with a request for
   an address from the home link.  The mobile node should include an
   INTERNAL_IP6_ADDRESS attribute in the CFG_REQUEST Payload.  The
   mobile node MAY also include the INTERNAL_IP6_SUBNET attribute if it
   wants to obtain information about the IPv6 prefixes on the home link.
   If the mobile node wants to configure a DNS server from the home link
   it can request for the DNS server information by including an
   INTERNAL_IP6_DNS attribute in the CFG_REQUEST payload.

   When the Home Agent receives a configuration payload with a
   CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid home
   address for the mobile node.  The INTERNAL_IP6_ADDRESS attribute in
   the CFG_REPLY contains the prefix length of the home prefix in
   addition to a 128 bit home address.  The Home Agent could use a local
   database or contact a DHCPv6 server on the home link to allocate a
   home address.  The Home Agent should also include an
   INTERNAL_ADDRESS_EXPIRY attribute to indicate to the mobile node, the
   duration for which the dynamically allocated home address is valid.

        Mobile Node                        Home Agent
        -----------                        ----------
        HDR, SK {IDi, [CERT,] [CERTREQ,]
                 [IDr,] AUTH, CP(CFG_REQUEST),
                 SAi2, TSi, TSr}
                                 -->

                                 <--   HDR, SK {IDr, [CERT,] AUTH,
                                                CP(CFG_REPLY), SAr2,
                                                TSi, TSr}

   The mobile node could suggest a home address that it wants to use in
   the CFG_REQUEST.  For example, this could be a home address that it
   was allocated before or could be an address the mobile node
   auto-configured from the IPv6 prefix on the home link.  The Home
   Agent could let the mobile node use the same home address by setting
   the INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload to the
   same home address.  If the Home Agent wants the mobile node to use a
   different home address, it sends a new home address in the
   INTERNAL_IP_ADDRESS attribute in the CFG_REPLY payload.  The Mobile
   Node MUST stop using its old home address and start using the newly
   allocated home address.

   In case the Home Agent is unable to allocate a home address for the
   mobile node during the IKE_AUTH exchange, it MUST send a Notify
   Payload with an INTERNAL_ADDRESS_FAILURE message.



Devarapalli              Expires August 24, 2005               [Page 19]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


   If the CFG_REQUEST from the mobile node had the INTERNAL_IP6_SUBNET
   attribute, the Home Agent SHOULD send prefix information for the all
   prefixes on the home link.  Note, that this prefix information in the
   INTERNAL_IP6_SUBNET does not carry all the information that is
   typically present when received through a router advertisement.  The
   mobile node should still rely on Mobile Prefix Discovery [2] to
   obtain complete information about the prefixes on the home link.












































Devarapalli              Expires August 24, 2005               [Page 20]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


8.  Security Considerations

   This document describes how IPsec can be used to secure Mobile IPv6
   signaling messages.  Please refer to RFC 3775 and RFC 3776 for
   security considerations related to the use of IPsec with Mobile IPv6.














































Devarapalli              Expires August 24, 2005               [Page 21]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


9.  IANA Considerations

   This document requires no action from IANA.
















































Devarapalli              Expires August 24, 2005               [Page 22]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


10.  Acknowledgements

   The author would like to thank Mika Joutsenvirta and Pasi Eronen for
   reviewing the draft.















































Devarapalli              Expires August 24, 2005               [Page 23]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


11.  References

11.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
        Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
        Agents", RFC 3776, June 2004.

   [4]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
        Internet-Draft draft-ietf-ipsec-ikev2-17, October 2004.

   [5]  Kent, S. and K. Seo, "Security Architecture for the Internet
        Protocol", Internet-Draft draft-ietf-ipsec-rfc2401bis-05,
        December 2004.

   [6]  Kent, S., "IP Encapsulating Security Payload (ESP)",
        Internet-Draft draft-ietf-ipsec-esp-v3-09, October 2004.

11.2  Informative References

   [7]   Giaretta, G., "Goals for AAA-HA interface",
         Internet-Draft draft-giaretta-mip6-aaa-ha-goals-00, September
         2004.

   [8]   Eronen, P., "Extension for EAP Authentication in IKEv2",
         Internet-Draft draft-eronen-ipsec-ikev2-eap-auth-02, October
         2004.

   [9]   Crocker, D., "Standard for the format of ARPA Internet text
         messages", STD 11, RFC 822, August 1982.

   [10]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
         Levkowetz, "Extensible Authentication Protocol (EAP)",
         RFC 3748, June 2004.

   [11]  Kent, S. and R. Atkinson, "Security Architecture for the
         Internet Protocol", RFC 2401, November 1998.

   [12]  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
         RFC 2409, November 1998.





Devarapalli              Expires August 24, 2005               [Page 24]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


Author's Address

   Vijay Devarapalli
   Nokia Research Center
   313 Fairchild Drive
   Mountain View, CA  94043
   USA

   Email: vijay.devarapalli@nokia.com










































Devarapalli              Expires August 24, 2005               [Page 25]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec February 2005


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 (2005).  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              Expires August 24, 2005               [Page 26]


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