[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                                           Azaire Networks
Updates: 3776 (if approved)                                    F. Dupont
Expires: October 14, 2006                                          CELAR
                                                          April 12, 2006


  Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture
                   draft-ietf-mip6-ikev2-ipsec-06.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 October 14, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

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








Devarapalli & Dupont    Expires October 14, 2006                [Page 1]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Packet Formats . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  General Requirements . . . . . . . . . . . . . . . . . . .  4
     4.2.  Policy Requirements  . . . . . . . . . . . . . . . . . . .  5
     4.3.  IPsec Protocol Processing Requirements . . . . . . . . . .  7
     4.4.  Dynamic Keying Requirements  . . . . . . . . . . . . . . .  8
   5.  Selector Granularity Considerations  . . . . . . . . . . . . .  9
   6.  Manual Configuration . . . . . . . . . . . . . . . . . . . . . 10
     6.1.  Binding Updates and Acknowledgements . . . . . . . . . . . 10
     6.2.  Return Routabililty Messages . . . . . . . . . . . . . . . 11
     6.3.  Mobile Prefix Discovery Messages . . . . . . . . . . . . . 12
     6.4.  Payload Packets  . . . . . . . . . . . . . . . . . . . . . 13
   7.  Dynamic Configuration  . . . . . . . . . . . . . . . . . . . . 13
     7.1.  Security Policy Database Entries . . . . . . . . . . . . . 13
       7.1.1.  Binding Updates and Acknowledgements . . . . . . . . . 14
       7.1.2.  Return Routability Messages  . . . . . . . . . . . . . 15
       7.1.3.  Mobile Prefix Discovery Messages . . . . . . . . . . . 15
       7.1.4.  Payload Packets  . . . . . . . . . . . . . . . . . . . 16
     7.2.  Security Association negotiation using IKEv2 . . . . . . . 17
     7.3.  Movements and Dynamic Keying . . . . . . . . . . . . . . . 19
   8.  The use of EAP authentication  . . . . . . . . . . . . . . . . 20
   9.  Dynamic Home Address Configuration . . . . . . . . . . . . . . 21
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     13.2. Informative References . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
   Intellectual Property and Copyright Statements . . . . . . . . . . 25

















Devarapalli & Dupont    Expires October 14, 2006                [Page 2]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 2006


1.  Introduction

   RFC 3776 describes how IPsec, as described in RFC 2401 [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 in RFC 4301 [5].  Among the
   many changes, the list of selectors has been expanded to include 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 4 lists the requirements.  Section 6 and Section 7 describe
   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].  Section 7.2 of 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 8.  A method
   for dynamically configuring a home address from the home agent using
   the Configuration Payload in IKEv2 is described in Section 9.


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.  Packet Formats

   The mobile node and the home agent MUST support the packet formats as
   defined in Section 3 of RFC 3776.



Devarapalli & Dupont    Expires October 14, 2006                [Page 3]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 2006


   In case the mobile node reverse tunnels all traffic including Mobile
   IPv6 signaling messages exchanged between the mobile node and the
   home agent, then the Home Address Option is not required to be
   present in the messages sent to the home agent.  The packet format
   for the binding update when sent in the tunnel mode looks as follows.

      IPv6 hdr (source = care-of address,
                destination = home agent)
      ESP header in tunnel mode
      IPv6 hdr (source = home address,
                destination = home agent)
      Mobility Header
         Binding Update
           Alternate Care-of Address option (care-of address)

   The binding acknowledgement sent to the mobile node when it is away
   from the home link looks as follows.

      IPv6 hdr (source = home agent,
                destination = care-of address)
      ESP header in tunnel mode
      IPv6 hdr (source = home agent,
                destination = home address)
      Mobility Header
         Binding Acknowledgement

   The packet formats for tunneled mobile prefix discovery messages is
   very similar with the home address as the source address in the inner
   IP header.


4.  Requirements

   This section describes mandatory rules and requirements for all
   Mobile IPv6 mobile nodes and home agents so that IPsec, with IKEv2 as
   the key negotiation protocol, can be used to protect traffic between
   the mobile node and the home agent.  Many of the requirements are
   repeated from RFC 3776 to make this document self-contained and
   complete.

4.1.  General Requirements

   o  RFC 3775 states that manual configuration of IPsec security
      associations MUST be supported and automated key management MAY be
      supported.  This document does not make any recommendations
      regarding the support of manual IPsec configuration and dynamic
      IPsec configuration.  This document just describes the use of
      manually created IPsec security associations and the use of IKEv2



Devarapalli & Dupont    Expires October 14, 2006                [Page 4]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 2006


      as the automated IPsec key management protocol for protecting
      Mobile IPv6 signaling messages.

   o  ESP encapsulation for Binding Updates and Binding Acknowledgements
      MUST be supported and used.

   o  ESP encapsulation in tunnel mode for the Home Test Init and Home
      Test messages tunneled between the mobile node and the home agent
      MUST be supported and SHOULD be used.

   o  ESP encapsulation of the ICMPv6 messages related to mobile prefix
      discovery MUST be supported and SHOULD be used.

   o  ESP encapsulation of the payload packets tunneled between the
      mobile node and the home agent MAY be supported and used.

   o  If multicast group membership control protocols or stateful
      address autoconfiguration protocols are supported, payload data
      protection MUST be supported for those protocols.

   o  The home agent and the mobile node MAY support authentication
      using EAP in IKEv2 as described in Section 8.

   o  The home agent and the mobile node MAY support remote
      configuration of home address as described in Section 9.  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 can pick a home address from a local
      database or from a DHCPv6 server on the home link.

4.2.  Policy Requirements

   The following requirements are related to the configuration of
   security policy database on the home agent and the mobile node.

   o  RFC 3776 required configuration of the security policies per
      interface in order to be able to differentiate between mobility
      header messages sent to the home agent and tunneled through the
      home agent to the correspondent node.  Since the Mobility Header
      message type is a selector, it is now easy to differentiate
      between HoTi and HoT messages from other mobility header messages.
      Therefore per-interface configuration of security policies is not
      required.

   o  The home agent MUST be able to prevent a mobile node from using
      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



Devarapalli & Dupont    Expires October 14, 2006                [Page 5]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 2006


      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 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  As required in the base specification [2], when a packet destined
      to the receiving node is matched against IPsec security policy or
      selectors of a security association, an address appearing in a
      Home Address destination option is considered as the source
      address of the packet.

      Note that the home address option appears before IPsec headers.
      Section 11.3.2 of the base specification describes one possible
      implementation approach for this: The IPsec policy operations can
      be performed at the time when the packet has not yet been modified
      per Mobile IPv6 rules, or has been brought back to its normal form
      after Mobile IPv6 processing.  That is, the processing of the Home
      Address option is seen as a fixed transformation of the packets
      that does not affect IPsec processing.

   o  Similarly, a home address within a Type 2 Routing header destined
      to the receiving node is considered as the destination address of
      the packet, when a packet is matched against IPsec security policy
      or selectors of a security association.

      Similar implementation considerations apply to the Routing header
      processing as was described above for the Home Address destination
      option.

   o  When the mobile node returns home and de-registers with the Home
      Agent, the tunnel between the home agent and the mobile node's
      care-of address is torn down.  The security policy entries, which
      were used for protecting tunneled traffic between the mobile node
      and the home agent MUST be made inactive (for instance, by
      removing them and installing them back later through an API).  The
      corresponding security associations could be kept as they are or
      deleted depending on how they were created.  If the security
      associations were created dynamically using IKE, they are
      automatically deleted when they expire.  If the security
      associations were created through manual configuration, they MUST
      be retained and used later when the mobile node moves away from
      home again.  The security associations protecting Binding Updates
      and Acknowledgements, and prefix discovery SHOULD NOT be deleted



Devarapalli & Dupont    Expires October 14, 2006                [Page 6]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 2006


      as they do not depend on care-of addresses and can be used again.

   o  The mobile node MUST use the Home Address destination option in
      Binding Updates and Mobile Prefix Solicitations, sent to the home
      agent from a care-of address, so that the home address is visible
      when the IPsec policy checks are made.

   o  The home agent MUST use the Type 2 Routing header in Binding
      Acknowledgements and Mobile Prefix Advertisements sent to the
      mobile node, again due to the need to have the home address
      visible when the policy checks are made.

4.3.  IPsec Protocol Processing Requirements

   The following lists requirements for IPsec processing at the Home
   Agent and the mobile node.

   o  The home agent and mobile node SHOULD support Mobility Header
      message type as an IPsec selector.

   o  The home agent and mobile node SHOULD 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  When securing Binding Updates, Binding Acknowledgements, and
      prefix discovery, both the mobile nodes and the home agents MUST
      support and SHOULD use the Encapsulating Security Payload (ESP)
      [6] header in transport mode and MUST use a non-null payload
      authentication algorithm to provide data origin authentication,
      connectionless integrity and optional anti-replay protection.

   o  Tunnel mode IPsec ESP MUST be supported and SHOULD be used for the
      protection of packets belonging to the return routability
      procedure.  A non-null encryption transform and a non-null
      authentication algorithm MUST be applied.

   o  When ESP is used to protect Binding Updates, there is no
      protection for the care-of address that appears in the IPv6 header
      outside the area protected by ESP.  It is important for the home
      agent to verify that the care-of address has not been tampered
      with.  As a result, the attacker would have redirected the mobile
      node's traffic to another address.  In order to prevent this,
      Mobile IPv6 implementations MUST use the Alternate Care-of Address
      mobility option in Binding Updates sent by mobile nodes while away



Devarapalli & Dupont    Expires October 14, 2006                [Page 7]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 2006


      from home.  The exception to this is when the mobile node returns
      home and sends a Binding Update to the home agent in order to de-
      register.

      When IPsec is used to protect return routability signaling or
      payload packets, the mobile node MUST set the source address it
      uses for the outgoing tunnel packets to the current primary care-
      of address.

   o  When IPsec is used to protect return routability signaling or
      payload packets, IPsec security associations are needed to provide
      this protection.  When the care-of address for the mobile node
      changes as a result of an accepted Binding Update, special
      treatment is needed for the next packets sent using these security
      associations.  The home agent MUST set the new care-of address as
      the destination address of these packets, as if the outer header
      destination address in the security association had changed.
      Similarly, the home agent starts to expect the new source address
      in the tunnel packets received from the mobile node.

      Such address changes can be implemented, for instance, through an
      API from the Mobile IPv6 implementation to the IPsec
      implementation.  One such API is described in [12].  It should be
      noted that the use of such an API and the address changes MUST
      only be done based on the Binding Updates received by the home
      agent and protected by the use of IPsec.  Address modifications
      based on other sources, such as Binding Updates to the
      correspondent nodes protected by return routability, or open
      access to an API from any application may result in security
      vulnerabilities.

4.4.  Dynamic Keying Requirements

   The following requirements are related to the use of a dynamic key
   management protocol by the mobile node and the home agent.
   Section 7.2 describes the use of IKEv2 as the dynamic key management
   protocol.

   o  The mobile node MUST use its care-of address as source address in
      protocol exchanges, when using dynamic keying.

   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
      as the initiator IP address in the TSi payload during the
      CREATE_CHILD_SA exchange [4].




Devarapalli & Dupont    Expires October 14, 2006                [Page 8]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 2006


   o  If the mobile node has used IKEv2 to establish security
      associations with its home agent, it should follow the procedures
      discussed in Section 11.7.1 and 11.7.3 of the base specification
      [2] to determine whether the IKE endpoints can be moved or if the
      IKE SA has to be re-established.

   o  If the home agent has used IKEv2 to establish security
      associations with the mobile node, it should follow the procedures
      discussed in Section 10.3.1 and 10.3.2 of the base specification
      [2] to determine whether the IKE endpoints can be moved or if the
      IKE SA has to be re-established.


5.  Selector Granularity Considerations

   IPsec implementations are compatible with this document even if they
   do not support fine grain selectors such as the Mobility Header
   message type and ICMPv6 message type.  For various reasons, some
   implementations may choose to support only coarse grain selectors
   (i.e., addresses and in some cases the protocol field) for forwarded
   traffic.  As finer grain selectors give better control, i.e., the
   protection is only applied when required, the examples in the
   document always use the finest granularity.

   The following describes different ways of setting up IPsec policies
   for protecting Mobile IPv6 messages:

   o  The IPsec implementations on the mobile node and the home agent
      support fine grain selectors, including the Mobility Header
      message type.  This is the case assumed in the IPsec SPD and SAD
      examples in this document.

   o  The IPsec implementations only support selectors at a protocol
      level.  In such implementations, the IPsec implementation can only
      identify mobility header traffic and cannot identify the
      individual mobility header messages.  In this case, the protection
      of Return Routability Messages uses a setup similar to the regular
      payload packets to the correspondent node with the protocol
      selector set to Mobility Header messages.  All tunneled Mobility
      Header messages will be protected.

   o  The third case is where the protocol selector is not available in
      the IPsec implementation.  In this case all traffic sent by the
      mobile node reverse tunneled through the home agent is protected
      using ESP in tunnel mode.  This case is also applicable when the
      mobile node, due to privacy considerations tunnels all traffic to
      the home agent.  This includes Mobile IPv6 signaling messages
      exchanged between the mobile node and the home agent and all



Devarapalli & Dupont    Expires October 14, 2006                [Page 9]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 2006


      traffic exchanged between the mobile node and the correspondent
      node.  This case uses IPsec tunnel mode SA with the protocol
      selector set to 'any'.

   The third case where all tunneled traffic is protected introduces
   some additional considerations:

   o  If there is just one IPsec SA providing protection for all
      traffic, then the SA MUST fulfill the requirements for protecting
      the Return Routability messages which require confidentiality
      protection.  If the third case is being used for privacy
      considerations, then there can also be separate tunnel mode SPD
      entries for protecting the Return Routability messages with a
      higher priority.

   o  The receipt of a Binding Update from the new care-of address
      updates the tunnel end point of the IPsec SA as described in
      Section 4.3.  Since the Binding Update that updates the tunnel end
      point is received through the same tunnel interface that needs to
      be updated, special care should be taken on the home agent to
      ensure that the Binding Update is not dropped.  This can be
      achieved by either performing the source address check on the
      outer IPv6 header after the binding update is processed or have
      exception handling to check the inner packet for a Binding Update
      when the source address match on the outer source address fails.
      Typical IPsec processing does not check the outer source address.


6.  Manual Configuration

   This section describes the SPD and SAD entries that can be used to
   protect Mobile IPv6 signaling messages.  The SPD and SAD entries are
   only example configurations.  A particular mobile node implementation
   and a home agent implementation could configure different SPD and SAD
   entries as long as they provide the required security of the Mobile
   IPv6 signaling messages.

   For the examples described in this document, a mobile node with home
   address, "home_address_1", primary care-of address,
   "care_of_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 be re-created or updated for the new home address.

6.1.  Binding Updates 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 & Dupont    Expires October 14, 2006               [Page 10]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 2006


        mobile node SPD-S:
          - IF source = home_address_1 & destination = home_agent_1 &
               proto = MH & local_mh_type =BU & remote_mh_type =
               BAck
            Then use SA SA1 (OUT) and SA2 (IN)

        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 & local_mh_type = BAck & remote_mh_type
               = BU
            Then use SA SA2 (OUT) and SA1 (IN)

        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

6.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 & Dupont    Expires October 14, 2006               [Page 11]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 2006


        mobile node SPD-S:
          - IF source = home_address_1 & destination = any &
            proto = MH & local_mh_type = HoTi & remote_mh_type = HoT
            Then use SA SA3 (OUT) and SA4 (IN)

        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 & local_mh_type = HoT & remote_mh_type =
            HoTi
            Then use SA SA4 (OUT) and SA3 (IN)

        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

6.3.  Mobile Prefix Discovery Messages

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




















Devarapalli & Dupont    Expires October 14, 2006               [Page 12]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 2006


        mobile node SPD-S:
          - IF source = home_address_1 & destination = home_agent_1 &
               proto = ICMPv6 & local_icmp6_type = MPS &
               remote_icmp6_type = MPA
            Then use SA SA5 (OUT) and SA6 (IN)

        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 & local_icmp6_type = MPA &
               remote_icmp6_type = MPS
            Then use SA SA6 (OUT) and SA5 (IN)

        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

6.4.  Payload Packets

   Regular payload traffic between the mobile node and the correspondent
   node 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.


7.  Dynamic Configuration

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

7.1.  Security Policy Database Entries

   The following sections describe the security policy entries on the
   mobile node and the home agent.  The SPD entries are only example
   configurations.  A particular mobile node implementation and a Home
   Agent implementation could configure different SPD entries as long as



Devarapalli & Dupont    Expires October 14, 2006               [Page 13]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 2006


   they provide the required security of the Mobile IPv6 signaling
   messages.

   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, he primary care-of address of the
   mobile node is assumed to be care_of_address_1 and the IPv6 address
   of the Home Agent is assumed to be home_agent_1.

7.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 source = home_address_1 & destination = home_agent_1 &
              proto = MH & local_mh_type = BU & remote_mh_type = BAck
           Then use SA ESP transport mode
                       IDi = user_1, IDr = home_agent_1,
                       TSi = home_address_1, MH, BU
                       TSr = home_agent_1, MH, BAck

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

   In the examples shown above, the home address of the mobile node
   might not be available all the time.  For instance, the mobile node
   might have not configured a home address yet.  When the mobile node
   acquires a new home address, it must either add the address to the
   corresponding SPD entries or create the SPD entries for the home
   address.

   The home agent should have named SPD entries per mobile node, based
   on the identity of the mobile node.  The identity of the mobile node
   is stored in the "Name" selector in the SPD [5].  The home address
   presented by the mobile node during the IKE negotiation is stored as
   the remote IP address in the resultant IPsec security associations.
   The home agent MAY also have generic SPD entries to prevent mobility
   header traffic that requires IPsec protection from bypassing the
   IPsec filters.

   The Mobility Header message type is negotiated by placing it in the
   most significant eight bits of the 16 bit local "port" selector



Devarapalli & Dupont    Expires October 14, 2006               [Page 14]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 2006


   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, we show only
   those values that are relevant for Mobile IPv6.

7.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 source = home_address_1 & destination = any &
              proto = MH & local_mh_type = HoTi &
              remote_mh_type = HoT
           Then use SA ESP tunnel mode
                       IDi = user_1, IDr = home_agent_1,
                       TSi = home_address_1, MH, HoTi
                       TSr = any, MH, HoT
                       outer src addr = care_of_address_1,
                       outer dst addr = home_agent_1,
                       inner src addr = home_address_1

       home agent SPD-S:
         - IF source = any & destination = home_address_1 &
              proto = MH & local_mh_type = HoT &
              remote_mh_type = HoTi
           Then use SA ESP tunnel mode
                       IDi = home_agent_1, IDr = user_1
                       TSi = any, MH, HoT
                       TSr = home_address_1, MH, HoTi
                       outer src addr = home_agent_1,
                       outer dst addr = care_of_address_1,
                       inner dst 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.

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








Devarapalli & Dupont    Expires October 14, 2006               [Page 15]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 2006


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

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

   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.

7.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 & Dupont    Expires October 14, 2006               [Page 16]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 2006


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

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

7.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.  A possible 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.  When a public key based
   mechanism is available, it should be the preferred mechanism for
   mutual authentication: private keys are used to generate the AUTH
   payload and identities are verified with certificate information
   transmitted by CERT payloads.  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 its IKE_AUTH third message.  Similarly, the home agent MAY
   exclude the CERTREQ payload in its IKE_SA_INIT second message 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.






Devarapalli & Dupont    Expires October 14, 2006               [Page 17]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 2006


        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 should always include 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.

   In the IKE_AUTH exchange, the mobile node includes the home address
   and the appropriate selectors in the TSi (Traffic Selector-initiator)
   payload to negotiate IPsec security associations for protecting the
   Binding Update and Binding Acknowledgement messages.  The mobile node
   MAY use a range of selectors that includes the mobility message types
   for Binding Update and Binding Acknowledgement to use the same pair
   of IPsec security association for both messages.

   After the IKE_AUTH exchange completes, the mobile node initiates
   CREATE_CHILD_SA exchanges to negotiate additional security
   associations for protecting 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.  If a correspondent node, that
   is also a mobile node, initiates the return routability exchange,
   then the home agent initiates the CREATE_CHILD_SA exchange to
   negotiate security associations for protecting Return Routabilty
   messages.

   It is important that the security associations are created based on
   the home address of the mobile node, so that the security
   associations survive care-of address change.  The mobile node MUST
   use its home address as the initiator IP address in the TSi payload



Devarapalli & Dupont    Expires October 14, 2006               [Page 18]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 2006


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

   When PKI based authentication is used between the mobile node and the
   Home Agent, the identity presented by the mobile node in the IDi
   payload must correspond to the identity in the certificate obtained
   by the Home Agent.  The home agent uses the identity presented in the
   IDi payload to lookup the policy and the certificate that corresponds
   to the mobile node.  If the mobile node presents its home address in
   the IDi payload, then the home agent MUST verify that the home
   address matches the address in the iPAddress field in the
   SubjectAltName extension [8].

   When the mobile node uses its home address in the IDi field,
   implementations are required to match the source address in the outer
   most IP header with the IP address in the IDi field [8].  This
   verification step, however, should be configurable [8].  With Mobile
   IPv6, this verification step will always fail because the source
   address in the IP header is the care-of address and the IP address in
   the IDi field is the home address.  Therefore, this verification step
   MUST be disabled.

7.3.  Movements and Dynamic Keying

   If the mobile node moves and its care-of address changes, the IKEv2
   SA might not be valid.  RFC 3775 defines a mechanism based on the
   successful exchange of Binding Update and Binding Acknowledgement
   messages.  The mobile node establishes the IKE SA with the home agent
   using its primary care-of address.  The IKE SA endpoints are updated
   on the home agent when it receives the Binding Update from the mobile
   node's new care-of address and on the mobile node when it sends the
   Binding Update to the home agent or when it receives the Binding
   acknowledgement sent by the home agent.  This capability to change
   IKE endpoints is indicated through setting the Key Management
   Capability (K) flag [2] in the Binding Update and Binding
   Acknowledgement messages.  If the mobile node or the home agent does
   not support this capability, then an IKEv2 exchange MUST be initiated
   to re-establish a new IKE SA.





Devarapalli & Dupont    Expires October 14, 2006               [Page 19]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 2006


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





Devarapalli & Dupont    Expires October 14, 2006               [Page 20]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 2006


9.  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_IP6_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 & Dupont    Expires October 14, 2006               [Page 21]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 2006


10.  Security Considerations

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

   A misbehaving mobile node could create IPsec security associations
   for a home address that belongs to another mobile node.  Therefore,
   the home agent should check if a particular mobile node is authorized
   to use a home address before creating IPsec security associations for
   the home address.  If the home address is assigned as described in
   Section 9, the home agent MUST associate the home address with the
   identity used in IKE negotiation.  The home agent MAY store the
   assigned home address in the SPD entries created for the mobile node.

   The use of EAP for authenticating the mobile node to the home agent
   is described in Section 8.  Security considerations related to the
   use of EAP with IKEv2 are described in [4].


11.  IANA Considerations

   This document requires no action from IANA.


12.  Acknowledgements

   The author would like to thank Mika Joutsenvirta, Pasi Eronen, Jari
   Arkko, Gerardo Giaretta and Shinta Sugimoto for reviewing the draft.

   Many of the requirements listed in Section 4 are copied from RFC
   3776.  Therefore, the authors of RFC 3776 are acknowledged.


13.  References

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




Devarapalli & Dupont    Expires October 14, 2006               [Page 22]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 2006


   [4]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
        December 2005.

   [5]  Kent, S. and K. Seo, "Security Architecture for the Internet
        Protocol", RFC 4301, December 2005.

   [6]  Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
        December 2005.

13.2.  Informative References

   [7]   Giaretta, G., "Goals for AAA-HA interface",
         draft-giaretta-mip6-aaa-ha-goals-00 (work in progress),
         September 2004.

   [8]   Korver, B., "The Internet IP Security PKI Profile of IKEv1/
         ISAKMP, IKEv2, and PKIX",
         draft-ietf-pki4ipsec-ikecert-profile-08 (work in progress),
         March 2006.

   [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]  Sugimoto, S., "PF_KEY Extension as an Interface between Mobile
         IPv6 and IPsec/IKE", draft-sugimoto-mip6-pfkey-migrate-02 (work
         in progress), March 2006.


















Devarapalli & Dupont    Expires October 14, 2006               [Page 23]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 2006


Authors' Addresses

   Vijay Devarapalli
   Azaire Networks
   4800 Great America Pkwy
   Santa Clara, CA  95054
   USA

   Email: vijay.devarapalli@azairenet.com


   Francis Dupont
   CELAR

   Email: Francis.Dupont@point6.net




































Devarapalli & Dupont    Expires October 14, 2006               [Page 24]

Internet-Draft      Mobile IPv6 with IKEv2 and IPsec          April 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 & Dupont    Expires October 14, 2006               [Page 25]


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