[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01

Network Working Group                                         A. Ebalard
Internet-Draft                                                      EADS
Intended status: Informational                                S. Decugis
Expires: February 19, 2009                                          NICT
                                                         August 18, 2008


   PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE
              draft-ebalard-mext-pfkey-enhanced-migrate-00

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 February 19, 2009.

Abstract

   This document describes the need for an interface between Mobile IPv6
   and IPsec/IKE and show how the two protocols can interwork.  An
   extension of the PF_KEY framework is proposed which allows smooth and
   solid operation of IKE in a Mobile IPv6 environment.

   This document is heavily based on a previous draft [MIGRATE] written
   by Shinta Sugimoto, Masahide Nakamura and Francis Dupont.  It simply
   reuses the MIGRATE mechanism defined in the expired document, removes
   a companion extension (SADB_X_EXT_PACKET) based on implementation
   feedback (complexity, limitations, ...) and fills the gap by very
   simple changes to MIGRATE mechanism.  This results in a more simple



Ebalard & Decugis       Expires February 19, 2009               [Page 1]


Internet-Draft      PF_KEY Extension for Mobile IPv6         August 2008


   and consistent mechanism, which also proved to be easier to
   implement.  This document is expected to serve as a continuation of
   [MIGRATE] work.  For that reason, the name of the extension has been
   kept.

   PF_KEY MIGRATE message serves as a carrier for updated address
   information for both the in-kernel IPsec structures (SP/SA) and those
   maintained by the key managers.  This includes in-kernel SP/SA
   endpoints, key manager maintained equivalents and addresses used by
   IKE_SA (current and to be negotiated).  The extension is helpful for
   assuring smooth internetworking between Mobile IPv6 and IPsec/IKE for
   the bootstrapping of mobile nodes and their movements.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Needs for Interactions between Mobile IPv6 and IPsec/IKE . . .  4
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  PF_KEY Extensions for Mobile IPv6: PF_KEY MIGRATE Message  . .  5
     5.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  5
       5.1.1.  System Overview  . . . . . . . . . . . . . . . . . . .  5
       5.1.2.  Bootstrapping  . . . . . . . . . . . . . . . . . . . .  7
       5.1.3.  Movement . . . . . . . . . . . . . . . . . . . . . . .  8
       5.1.4.  IKE_SA Update  . . . . . . . . . . . . . . . . . . . .  9
     5.2.  Issuing PF_KEY MIGRATE Message . . . . . . . . . . . . . . 10
     5.3.  Processing PF_KEY MIGRATE Message  . . . . . . . . . . . . 11
     5.4.  Applicability of PF_KEY MIGRATE to Other Systems . . . . . 12
     5.5.  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . . 13
     5.6.  Limitations of PF_KEY MIGRATE  . . . . . . . . . . . . . . 13
   6.  Necessary Modifications to Mobile IPv6 and IPsec/IKE . . . . . 13
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Appendix A.  PF_KEY MIGRATE Message Format . . . . . . . . . . . . 16
   Appendix B.  Acknowledgements  . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 21










Ebalard & Decugis       Expires February 19, 2009               [Page 2]


Internet-Draft      PF_KEY Extension for Mobile IPv6         August 2008


1.  Introduction

   In Mobile IPv6 [RFC3775], the Mobile Node (MN) and the Home Agent
   (HA) use some IPsec Security Associations (SAs) in tunnel mode to
   protect some mobility signaling messages, mobile prefix discovery and
   optionally payload traffic.  Since the MN may change its attachment
   point to the Internet, it is necessary for it to update the tunnel
   endpoint address of its IPsec SAs.  This indicates that corresponding
   entries in IPsec databases (Security Policy (SPD) and SA (SAD)
   databases) should be updated when MN performs movements.

   In a Mobile IPv6 environment, a key manager also needs to be notified
   when the SPD and SAD are updated.  More generally, it needs to be
   provided with updated addresses for already negotiated and future
   IKE_SA.  Because of its role and unlike common applications, key
   managers have to take part to the mobility process they secure: they
   need to be aware of address changes.

   This document describes the need for an interface between Mobile IPv6
   and IPsec/IKE and shows how the two protocols can interwork.  An
   extension to the PF_KEY framework [RFC2367] which allows smooth and
   solid operation of IKE in a Mobile IPv6 environment is defined in the
   document.  The extension is called PF_KEY MIGRATE and serves as a
   carrier for the necessary information for both the in-kernel IPsec
   stack and the key managers.

   For the IPsec stack, this allows migrating the endpoint addresses of
   the IPsec SAs (and associated SP).  For the key managers, this allows
   the mirrored structures to be updated (SAD and SPD).  This also
   allows the addresses of already negotiated and associated IKE_SA to
   be migrated, and to make specific addresses available for
   negotiations of future IKE_SA.  This set of operations performed by
   the KM on its internal structures is initiated by the MIPv6 process.

   With the extension, the bootstrapping of the MN appears as a common
   operation for IKE, by having the right addresses needed for the
   negotiation available prior to the reception of the ACQUIRE message.

   The extension is helpful for assuring smooth interworking between
   Mobile IPv6 and IPsec/IKE and achieving performance optimization.

   As stated in the abstract, this document is heavily based on the
   content of a previous draft MIGRATE [MIGRATE].  This expired memo
   served as the basis for this work both from technical and editorial
   standpoints.  Numerous technical discussions with some of its authors
   took place while working on this memo.





Ebalard & Decugis       Expires February 19, 2009               [Page 3]


Internet-Draft      PF_KEY Extension for Mobile IPv6         August 2008


2.  Terminology

   In this document, the term IKE implicitly stands for both IKEv1
   [RFC2409] and IKEv2 [RFC4306].  IKEv2 terminology is used
   preferentially when describing actions performed by the key manager
   but they also apply to the IKEv1 counterparts.  For instance, when
   actions occur on IKE_SA, they also apply to Phase 1 for IKEv1, except
   otherwise specified.  Key manager is used as a more generic term in
   the memo to refer to the IKE daemon.


3.  Needs for Interactions between Mobile IPv6 and IPsec/IKE

   The section 4.4 of RFC 3776 [RFC3776] specifies the rules which apply
   to IKE for MNs and HAs.  The first requirement is to run IKE over the
   Care-of Address (CoA) because the Home Address (HoA) is usable only
   after the home registration but not yet in the bootstrapping phase,
   when Transport mode IPsec SA are commonly negotiated to protect
   BU/BA.

   A tunnel IPsec SA pair protects some signaling messages and
   optionally all the traffic between the MN and HA.  The initial SPD
   entry uses the HoA for the MN endpoint address and updates this
   address to the new CoA at each movement.  A tunnel SA pair is created
   on demand and is updated too.  The RFC 3775 [RFC3775] assumes there
   is an API which performs the update in the SPD and SAD on both the MN
   and HA, and notify the IKE daemon.  This document is mainly about
   this API.

   Mobile IPv6 may need to make an access to the SPD not only for
   updating an endpoint address but also for deleting/inserting a
   specific SPD entry.  When the MN performs Foreign-to-Home movement,
   IPsec SAs established between the MN and HA should be deleted, which
   means that the SPD entry should have no effect anymore.  On the other
   hand, when the MN performs Home-to-Foreign movement, the IPsec SAs
   should be restored.  Hence security policy entries that are
   associated with tunnel mode SAs may dynamically be added/removed
   (enabled/disabled) in along with MN's movements.

   It should be noted that NEMO Basic Support [RFC3963] has similar
   requirements for the Mobile Router (MR) and MR's HA (MRHA).  In NEMO,
   the MR works just like a MN registering its location information to
   the MRHA and establishes a tunnel (IP-in-IP or IPsec tunnel).  When
   an IPsec tunnel is established between MR and MRHA, the MR serves as
   a Security Gateway for the nodes connected to the mobile network.
   The MR is responsible for handling its tunnel endpoint properly.





Ebalard & Decugis       Expires February 19, 2009               [Page 4]


Internet-Draft      PF_KEY Extension for Mobile IPv6         August 2008


4.  Requirements

   Despite the need for an interface between Mobile IPv6 and IPsec/IKE,
   it should be kept simple.  Following are the requirements for the
   interface from a software engineering point of view.

   o  Necessary modifications to the existing software, namely Mobile
      IPv6 and IPsec/IKE, in order to realize proposed mechanisms,
      should be kept minimum.
   o  Proposed mechanism should not be platform dependent.  The
      mechanism should be based on technology which is commonly
      available on various platform.  This seems to be essential for
      achieving high portability of the implementation which supports
      proposed mechanisms.


5.  PF_KEY Extensions for Mobile IPv6: PF_KEY MIGRATE Message

   In order to fulfill the needs and requirements described in Section 3
   and Section 4 we propose to extend the PF_KEY framework so that
   Mobile IPv6 and IPsec/IKE can interact with each other.  The new
   message dedicated to that function is called MIGRATE.  A new simple
   PF_KEY structure (sadb_x_kmaddress) is also defined to be used by
   MIGRATE to serve the purpose of IKE_SA update.

5.1.  Overview

5.1.1.  System Overview

   The MIGRATE message is used for providing updated information to its
   two targets, the kernel IPsec stack and the key manager (when used).
   The figure below illustrates how Mobile IPv6 and IPsec/IKE components
   interact with each other using PF_KEY MIGRATE message in a dynamic
   keying scenario.  On left top is a Mobile IPv6 entity (it may be
   possible that Mobile IPv6 component is completely implemented inside
   the kernel).  In any case, Mobile IPv6 should be the one which issues
   the MIGRATE message.  On right top is an IKE daemon which is
   responsible for establishing SAs required for Mobile IPv6 operation.
   In a manual keying scenario, the difference is mainly that there is
   no IKE daemon running on the system.











Ebalard & Decugis       Expires February 19, 2009               [Page 5]


Internet-Draft      PF_KEY Extension for Mobile IPv6         August 2008


                  +-------------+           +------------+
                  |             |           |            |
                  | Mobile IPv6 |           | IKE Daemon |
                  |             |           |            |
                  +-------------+           +------------+
                         | 1. PF_KEY               A 4. Update SPD & SAD
                         |    MIGRATE              | 5. Update IKE_SA
                         +-----------+ +-----------+
                                     | |
      Userland                       V |
     ==========================[PF_KEY Socket]========================
      Kernel                         | |
                          +----------+ +----------+
                          | 2. Update             | 3. Update
                          V    SPD                V    SAD
                    +-----------+           +------------+
                    |           |           |            |
                    |    SPD    |           |    SAD     |
                    |           |           |            |
                    +-----------+           +------------+

   In the kernel, the primary role of PF_KEY MIGRATE message is to
   migrate endpoint addresses of SA pairs, which results in requesting
   IPsec to update its databases (SPD and SAD).  Even if tunnel mode is
   the primary target for MIPv6, MIGRATE is not limited to that mode
   (See Section 5.4).  Then, after proper processing by the kernel, the
   MIGRATE message is sent to all open sockets.  A listening key manager
   processes it, which results in a possible update of its internal
   structures.  The specific actions are introduced on the following
   figure.

      MIPv6 ---------------- kernel -------------------> IKE
     process
                       1) update of SP        1) Update of SA and SP
                         endpoints and           endpoints (in image)
                         associated SA.       2) Update of src and dst
                                                 @ in SPD image for
                                                 future SA negotiation
                                              3) Update of IKE_SA src
                                                 and dst @ associated
                                                 with provided SA

   In more details, the processing of a MIGRATE message is done in
   following steps:

   o  Mobile IPv6 issues a PF_KEY MIGRATE message to the PF_KEY socket.





Ebalard & Decugis       Expires February 19, 2009               [Page 6]


Internet-Draft      PF_KEY Extension for Mobile IPv6         August 2008


   o  The operating system (kernel) validates the message and checks if
      corresponding security policy entry exists in SPD.
   o  When the message is confirmed to be valid, the SPD entry is
      updated according to the MIGRATE message.  If there is any target
      SA found that is also target of the update, it should also be
      updated.
   o  After the MIGRATE has beensuccessfully processed inside the
      kernel, it is sent to all open PF_KEY sockets.
   o  The IKE daemon receives the MIGRATE message from its PF_KEY socket
      and validates it.
   o  The key manager starts by updating the SP entries described in the
      message with the updated endpoint information.  It also updates in
      its SPD image the local and remote addresses to be used for future
      negotiation of SA associated with those SP (addresses used by
      future IKE_SA).  Then, it updates the SA related information: the
      endpoints of already negotiated SA and the local and remote values
      of associated IKE_SA.

   Note that the way IKE maintains its local copy of SPD (the SPD image)
   is an implementation specific issue since there is no standard
   interface to access SPD.  Some IKE implementations may continuously
   monitor the SPD inside the kernel.  Some IKE implementation may
   expect notifications from the kernel when the SPD is modified.  In
   either way, the proposed mechanism gives a chance for IKE to keep its
   SPD image up-to-date which is significant in Mobile IPv6 operation.

5.1.2.  Bootstrapping

   In the bootstrapping stage of Mobile IPv6, the MN and the HA need to
   establish IPsec SA to protect signaling messages of Mobile IPv6 such
   as BU and BA.  When IKE is used to establish and maintain the SA
   pairs, the IKE negotiation is the very first transaction made between
   the MN and the HA.

   As mentioned in [RFC3776], some care is needed for the address
   management of the IKE negotiation in Mobile IPv6 environments.  In
   particular, IKE negotiation to be made to establish a transport mode
   IPsec SA pair is tricky because the local IKE_SA address and the SA
   endpoint on the MN side (the Home Address) are different.  This is
   because the home address cannot be used prior to the initial home
   registration.  Even if the SADB_X_EXT_KMADDRESS extension defined in
   this memo enables the MIPv6 module to notify the IKE module about the
   IKE endpoint, address selection is left outside the scope of the
   document.  In practice, a suitable candidate for the IKE endpoint is
   the primary CoA.

   A simple solution to have the key manager be aware that a different
   address must be used for the negotiation of SA is to have it record



Ebalard & Decugis       Expires February 19, 2009               [Page 7]


Internet-Draft      PF_KEY Extension for Mobile IPv6         August 2008


   this address within its mirrored SPD entries as soon as it becomes
   available.  With that information, it is able to inflect its usual
   processing where it selects by default the source address of the SA
   for the negotiation (i.e. as local address of the IKE_SA).  By having
   the MIGRATE message emitted by the Mobile IPv6 process before the
   emission of the BU, the address is already available to the key
   manager when the ACQUIRE message is received.

   Even if the bootstrapping process initially appears differently than
   the usual process, having the internal structure of the key manager
   explicitly record the address (to be used for the negotiation of the
   SA for a specific SP) allows to keep things simple.  The only
   requirement is that the MIGRATE message be emitted by the Mobile IPv6
   process before it sends its Binding Update.

5.1.3.  Movement

   Next, we will see how migration takes place in along with home
   registration.  The figure below shows sequence of mobility signaling
   and PF_KEY MIGRATE messages while the MN roams around links.  It is
   assumed that in the initial state the tunnel endpoint address for a
   given MN is set as its home address.  In the initial home
   registration, the MN and HA migrate the tunnel endpoint address from
   the HoA to CoA1.  It should be noted that no migration takes place
   when the MN performs re-registration since the care-of address
   remains the same.  Accordingly, the MN performs movement and changes
   its primary care-of address from CoA1 to CoA2.  A PF_KEY MIGRATE
   message is issued on both MN and HA for each direction.  When the MN
   returns to home, migration takes place updating the endpoint address
   with the MN's home address.

   With regard to the timing of issuing the MIGRATE message on the MN
   side during a handover, it must occur immediately before the emission
   of the binding update performing the home registration (as for
   bootstrapping).  It is possible that ESP-protected (IPsec tunneled)
   user traffic be sent from the new CoA which is not known to the HA
   yet.  As the HA processes the packets under IPsec, and as far as it
   finds a valid SA, then those packets will be authenticated regardless
   of their source IP address.  In the end, there is no security issue
   in updating the IPsec SA endpoint while sending the BU and no reason
   not to do it.  Furthermore, this may help the MN to minimize the
   packet loss of its outbound traffic during the handover.









Ebalard & Decugis       Expires February 19, 2009               [Page 8]


Internet-Draft      PF_KEY Extension for Mobile IPv6         August 2008


               MN                                        HA
               |                                          |
               ~                                          ~
     Movement->|
     MIGRATE ->|      BU (Initial home registration)      |
    (HoA->CoA1)|----------------------------------------->|
               |                   BA                     |<- MIGRATE
               |<-----------------------------------------| (HoA->CoA1)
               |                                          |
               ~         BU (Home re-registration)        ~
               |----------------------------------------->|
               |                   BA                     |
               |<-----------------------------------------|
               |                                          |
               ~                                          ~
               |                                          |
     Movement->|           BU (Home registration)         |
     MIGRATE ->|                   BA                     |
   (CoA1->CoA2)|----------------------------------------->|
               |                                          |<- MIGRATE
               |<-----------------------------------------| (CoA1->CoA2)
               |                                          |
               ~                                          ~
     Movement->|         BU (Home de-registration)        |
     MIGRATE ->|                   BA                     |
    (CoA2->HoA)|----------------------------------------->|
               |                                          |<- MIGRATE
               |<-----------------------------------------| (CoA2->HoA)
               |                                          |

5.1.4.  IKE_SA Update

   The bootstrapping process described in Section 5.1.2 allows the
   creation of the SA by having the right source address available to
   the key manager before the beginning of the negotiation.  When the SA
   has been negotiated, some further exchanges are expected to happen
   during the lifetime of the SA, including rekeying related exchanges.
   After the first movement (and obviously further ones), the address
   used during the bootstrapping process becomes invalid.  Even if the
   SPD and SAD entries are updated (as described in Section 5.1.1),
   there is also a need for the key manager to update the addresses used
   by the IKE_SA.

   When the key manager processes the MIGRATE message, it uses the local
   and remote address information provided by the sadb_x_kmaddress
   structure to update:





Ebalard & Decugis       Expires February 19, 2009               [Page 9]


Internet-Draft      PF_KEY Extension for Mobile IPv6         August 2008


   o  local copy of the SP entry maintained by the IKE daemon which is
      specified in the MIGRATE message (as described in Section 5.1.2).
   o  the existing IKE_SA associated with the SP entry which is
      specified by the MIGRATE message.

5.2.  Issuing PF_KEY MIGRATE Message

   The Mobile IPv6 entity (MN or HA) code triggers the migration by
   sending a PF_KEY MIGRATE message to its PF_KEY socket.  Conceptually,
   the PF_KEY MIGRATE message should contain following information:

    o  Key manager address information                 \
       *  source address                                |  For IKE only
       *  destination address                          /
    o  Selector information:                           \
       *  source address/port                           |
       *  destination address/port                      |
       *  upper layer protocol (i.e., Mobility Header)  |
       *  direction (inbound/outbound)                  |
    o  Old SA information:                              |
       *  old source endpoint address                   |  For IKE and
       *  old destination endpoint address              |  IPsec stack
       *  IPsec protocol (ESP/AH)                       |
       *  mode (Tunnel/Transport/BEET)                  |
    o  New SA information:                              |
       *  new source endpoint address                   |
       *  new destination endpoint address              |
       *  IPsec protocol (ESP/AH)                       |
       *  mode (Tunnel/Transport/BEET)                 /

   Key manager address information content (source and destination
   address) is recorded in the associated entry of the SPD image.  Those
   are used from now on by the key manager for SA negotiation associated
   with that SP.  The information is also used by the key manager to
   update the local and remote addresses of the IKE_SA (used by already
   negotiated SA associated with the SP).

   Selector information is required for specifying the target SPD entry
   to be updated.  Basically the information should contain necessary
   elements which characterize traffic selector as specified in the
   IPsec architecture ([RFC2401], [RFC4301]).  With regard to the upper
   layer protocol, when the Mobile IPv6 stack is not fully aware of
   IPsec configuration, a wildcard value could be given.  In such case,
   an upper layer protocol information should not be taken into account
   for searching SPD entry.  Plus, the direction of the security policy
   (inbound/outbound) should be provided.

   The old SA information, along with old locator information is used to



Ebalard & Decugis       Expires February 19, 2009              [Page 10]


Internet-Draft      PF_KEY Extension for Mobile IPv6         August 2008


   specify target SA to be updated.  For tunnel and BEET
   [I-D.nikander-esp-beet-mode] modes, the endpoint addresses refer to
   the source and destination IP addresses that appear in the IP header,
   and those should be provided by the MIGRATE message.  For transport
   mode, we require it to be present to keep a fixed message format.
   For all modes, the address information represents the locators of the
   SA.  For transport mode, it must match with the addresses provided in
   the selector.  For tunnel mode, it is obviously not required.

   The source and destination addresses (locators) of the target entry
   should be overwritten.  New locator values should also be used to
   update SP.  Note that the IPsec protocol and mode fields should not
   be updated by a PF_KEY MIGRATE message.

   A PF_KEY MIGRATE message should be formed, based on security policy
   configuration and binding record.  The selector information and some
   parts of the SA information (IPsec protocol and mode) should be taken
   from the policy configuration.  The rest of the information should be
   taken from the sequential binding information.  For example, in the
   case where the MN updates its inbound security policy and
   corresponding tunnel mode SA pair, the old source address should be
   set as its previous CoA, and the new source address should be set as
   its current CoA.  Hence, the MN should sequentially keep track of its
   CoA record.  Such information shall be stored in binding update list
   entry.  For the same reason, the HA should keep track of previous
   CoAs of MNs.  Such information shall be stored in binding cache
   entry.  In previous scenario, the source and destination entries of
   the address information for the key manager should respectively be
   set to the CoA and the address of the HA.

   A detailed format of MIGRATE message is provided in Appendix A.

5.3.  Processing PF_KEY MIGRATE Message

   Since a PF_KEY MIGRATE message is applied to a single SPD entry, the
   kernel should first check validity of the message.  During that
   process, it simply skips sadb_x_kmaddress structure content.  If the
   message is invalid, an EINVAL error MUST be returned as a return
   value for the write() operation made to the PF_KEY socket.  After the
   validation, the kernel checks if the target SPD entry really exists.
   If no entry is found, an ENOENT error MUST be returned.  If a SPD
   entry is found and successfully updated, a success (0) MUST be
   returned regardless of subsequent result of SAD lookup/update.  Note
   that there may be cases where a corresponding SAD entry does not
   exist even if a SPD entry is successfully updated.  In any error
   case, a PF_KEY MIGRATE message MUST NOT have any effect on the SPD
   and SAD.




Ebalard & Decugis       Expires February 19, 2009              [Page 11]


Internet-Draft      PF_KEY Extension for Mobile IPv6         August 2008


   With respect to the behavior of a normal process (including the IKE
   daemon) which receives a PF_KEY MIGRATE message from a PF_KEY socket,
   it SHOULD first check if the message does not include erroneous
   information.  When there is any error indicated, the process MUST
   silently discard the PF_KEY MIGRATE message.  Otherwise, the
   processing of the message may continue.  This implies that the kernel
   is the only entity responsible for returning a status regarding
   message validation.

5.4.  Applicability of PF_KEY MIGRATE to Other Systems

   The PF_KEY MIGRATE extension can also be applied to other systems
   than Mobile IPv6.  In some systems, there is a need to update
   endpoint address of IPsec security association for various reasons
   such as mobility management and multihoming.

   In a Mobile VPN scenario (aka "road warrior"), client node roams
   around different IP subnets while maintaining security associations
   with the security gateway.  Just like in Mobile IPv6 case, both of
   the IKE peers need to update the endpoint of the IPsec tunnel and
   PF_KEY MIGRATE message can be used for that purpose.

   In HIP mobility management scenario [RFC5206], a mobile host can
   maintain a HIP association with its peer while moving around IP
   subnets.  When the mobile host changes its attachment point to the
   Internet, it sends an UPDATE message to the peer reporting its new
   locator.  Since HIP association is represented by an IPsec security
   association of ESP BEET mode, the same mechanism can be applied for
   the purpose of updating endpoint.  The procedure of MIGRATE can take
   place when the mobile host detects movement and when the peer
   receives the UPDATE message.

   From the ID/Locator separation point of view, PF_KEY MIGRATE is
   designed to update locators stored in an IPsec security association.
   Even if this usually applies to IPsec security associations in tunnel
   mode, the MIGRATE framework also covers the transport mode.  For
   instance, there are exceptional cases where IPsec security
   associations are bundled.  In some case, a transport mode security
   association may be bundled with a tunnel mode security association.
   For instance, a combination of AH (transport mode) and ESP (tunnel
   mode) may assure confidentiality of the payload as well as data
   integritiy of the whole IP packet including outer header.  In such
   case, PF_KEY MIGRATE message may be used for updating endpoint
   addresses of IPsec transport mode.







Ebalard & Decugis       Expires February 19, 2009              [Page 12]


Internet-Draft      PF_KEY Extension for Mobile IPv6         August 2008


5.5.  NAT Traversal

   Dual Stack Mobile IPv6 [I-D.ietf-mext-nemo-v4traversal] supports a
   scenario where a MN is connected to a network behind a Network
   Address Translator (NAT).  In such case, the MN assigns a IPv4
   private address to its network interface but it is still capable of
   registering its care-of address to the HA, using the NAT Traversal
   technique [RFC3948].  The MN and HA leverage an IPsec tunnel to
   protect the return routability messages.

   It is possible for the PF_KEY MIGRATE message to handle IPv4 private
   address when the MN is behind a NAT device.  In a NAT Traversal case,
   the endpoint address of the MN is characterized by the IP address and
   the pair of source and destination port numbers used for the UDP
   encapsulation.  Therefore, in a NAT Traversal scenario, a Mobile IPv6
   module MUST issue a PF_KEY MIGRATE message along with the pair of
   source and destination port numbers of a UDP encpasulation, to handle
   IPv4 private address.

5.6.  Limitations of PF_KEY MIGRATE

   Currently, a Security Parameter Index (SPI) is not included in the
   old SA information to specify target SAD entry.  This helps to lessen
   operational burden of Mobile IPv6.  However, this simplification can
   produce ambiguity in searching for the target security association
   entry.  When the unique SPD level is available, it should be used
   because it avoids this problem both by marking the SAs to update and
   by limiting SA sharing.

   It should be noted that delivery of PF_KEY MIGRATE messages cannot be
   guaranteed, which is common to other PF_KEY messages.  It may be
   possible (even if highly unlikely) that a MIGRATE message be lost.
   In such case, there will be inconsistency between the binding record
   managed by Mobile IPv6 and IPsec database inside the kernel or the
   IKE daemon.  Once a PF_KEY MIGRATE message is lost, it would not be
   possible for the receiver to process some subsequent MIGRATE messages
   properly.  Reinitialization of the Mobile IPv6 stack and IPsec
   databases may be needed for recovery.


6.  Necessary Modifications to Mobile IPv6 and IPsec/IKE

   In order to realize the proposed mechanism, there are some necessary
   modifications to Mobile IPv6 and IPsec/IKE.  They are listed below
   for implementors of Mobile IPv6 and/or IPsec/IKE.






Ebalard & Decugis       Expires February 19, 2009              [Page 13]


Internet-Draft      PF_KEY Extension for Mobile IPv6         August 2008


   o  Modifications to Mobile IPv6:
      *  The Mobile IPv6 code needs to make an access to PF_KEY socket.
         In particular, the Mobile IPv6 code should have privilege to
         write messages into a PF_KEY socket.
      *  Issuing PF_KEY MIGRATE messages: in order to send MIGRATE
         messages, it is required that the Mobile IPv6 code has some
         knowledge of its IPsec configuration and precise binding
         record.  The Mobile IPv6 code may be aware of exact IPsec
         configuration in form of security policy.  It would also be
         possible that the Mobile IPv6 code is only aware of minimum
         IPsec configuration whether IPsec is utilized or not.
      *  With regard to the emission of the MIGRATE message during the
         home registration, the Mobile IPv6 code need to emit it before
         issuing the Binding Update.
   o  Modifications to IPsec:
      *  Processing PF_KEY MIGRATE messages: the kernel should be able
         to process PF_KEY MIGRATE messages sent by the Mobile IPv6
         code.  Unless the message is invalid, it should be sent to all
         open PF_KEY sockets.
   o  Modifications to IKE (associated with processing of MIGRATE):
      *  the IKE code need to update its local copy of IPsec databases
         (SPD and SAD) in accordance with received PF_KEY MIGRATE
         message.
      *  the IKE code need to update its associated IKE_SA with new
         local and remote addresses specifically provided in PF_KEY
         MIGRATE messages (in sadb_x_kmaddress structure).  It also
         needs to maintain in its SPD the addresses to be used for
         future negotiation of IKE_SA.


7.  Security Considerations

   There is no specific security considerations for the mechanisms
   introduced by the document but as it makes deployment of dynamic
   keying in Mobile IPv6 environments easier it should improve the
   security of such environments.  Note that dynamic keying is known to
   be more secure (it provides anti-replay for instance) and far more
   scalable.


8.  Conclusion

   o  There is a need for Mobile IPv6 and IPsec/IKE to interact with
      each other to provide full support of IPsec security functions.
   o  An extension to the PF_KEY framework (PF_KEY MIGRATE message) is
      proposed, which makes it possible:





Ebalard & Decugis       Expires February 19, 2009              [Page 14]


Internet-Draft      PF_KEY Extension for Mobile IPv6         August 2008


      *  for the IPsec/IKE to migrate endpoint addresses IPsec SAs from
         one to another.
      *  to make the source address to be used by the key manager for SA
         negotiation available before it is needed.
      *  to update addresses of IKE_SA after movement.
   o  An additional requirement associated with the solution for IKE is
      the addition in SPD image of additional per-SP hints to be used as
      addresses for negotiation of SAs.
   o  Currently, large portion of the proposed mechanism is
      implementation dependent due to lack of standard interface to
      access the SPD (PF_POLICY?).


9.  References

9.1.  Normative References

   [RFC2367]  McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
              Management API, Version 2", RFC 2367, July 1998.

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

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

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC3776]  Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
              Protect Mobile IPv6 Signaling Between Mobile Nodes and
              Home Agents", RFC 3776, June 2004.

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

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

9.2.  Informative References

   [I-D.ietf-mext-nemo-v4traversal]
              Soliman, H., "Mobile IPv6 support for dual stack Hosts and
              Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-05
              (work in progress), July 2008.

   [I-D.nikander-esp-beet-mode]
              Melen, J. and P. Nikander, "A Bound End-to-End Tunnel



Ebalard & Decugis       Expires February 19, 2009              [Page 15]


Internet-Draft      PF_KEY Extension for Mobile IPv6         August 2008


              (BEET) mode for ESP", draft-nikander-esp-beet-mode-09
              (work in progress), August 2008.

   [MIGRATE]  Sugimoto, S., Nakamura, M., and F. Dupont, "PF_KEY
              Extension as an Interface between Mobile IPv6 and IPsec/
              IKE", draft-sugimoto-mip6-pfkey-migrate-04 (work in
              progress), December 2007.

   [RFC3948]  Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
              Stenberg, "UDP Encapsulation of IPsec ESP Packets",
              RFC 3948, January 2005.

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, January 2005.

   [RFC5206]  Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
              Host Mobility and Multihoming with the Host Identity
              Protocol", RFC 5206, April 2008.


Appendix A.  PF_KEY MIGRATE Message Format

   The figure below shows the message format of PF_KEY MIGRATE.  The
   message consists of 7 parts (boundary of each part is marked with
   ">").  The message starts with PF_KEY base message header directly
   followed by a sadb_x_kmaddress{} structure.  The extension holds the
   two IKE_SA local and remote addresses as opaque data for the key
   manager (two 64-bit aligned sockaddr).  It is then followed by two
   address extensions: those respectively hold source and destination
   addresses of the selector.  The rest of the message is specific to
   IPsec implementations on BSD and Linux. sadb_x_policy{} structure
   holds additional information of security policy.  The last part of
   the message is a pair of sadb_x_ipsecrequest{} structures that hold
   old and new SA information.

      0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
     +---------------+---------------+---------------+---------------+
     |  ...version   | sadb_msg_type | sadb_msg_errno| ...msg_satype |
     +---------------+---------------+---------------+---------------+
     |          sadb_msg_len         |       sadb_msg_reserved       |
     +---------------+---------------+---------------+---------------+
     |                         sadb_msg_seq                          |
     +---------------+---------------+---------------+---------------+
     |                         sadb_msg_pid                          |
    >+---------------+---------------+---------------+---------------+
     |     sadb_x_kmaddress_len      |   sadb_x_kmaddress_exttype    |
     +---------------+---------------+---------------+---------------+



Ebalard & Decugis       Expires February 19, 2009              [Page 16]


Internet-Draft      PF_KEY Extension for Mobile IPv6         August 2008


     |                    sadb_x_kmaddress_reserved                  |
     +---------------+---------------+---------------+---------------+
     ~         IKE_SA local address            (64-bit aligned ...   ~
     +---------------+---------------+---------------+---------------+
     ~         IKE_SA remote address           ... pair of sockaddr) ~
    >+---------------+---------------+---------------+---------------+
     |       sadb_address_len        |     sadb_address_exttype      |
     +---------------+---------------+---------------+---------------+
     | _address_proto| ..._prefixlen |     sadb_address_reserved     |
     +---------------+---------------+---------------+---------------+
     ~         selector source address (64-bit aligned sockaddr)     ~
    >+---------------+---------------+---------------+---------------+
     |       sadb_address_len        |     sadb_address_exttype      |
     +---------------+---------------+---------------+---------------+
     | _address_proto| ..._prefixlen |     sadb_address_reserved     |
     +---------------+---------------+---------------+---------------+
     ~     selector destination address (64-bit aligned sockaddr)    ~
    >+---------------+---------------+---------------+---------------+
     |       sadb_x_policy_len       |     sadb_x_policy_exttype     |
     +---------------+---------------+---------------+---------------+
     |       sadb_x_policy_type      |     ..._dir   |  ..._reserved |
     +---------------+---------------+---------------+---------------+
     |                        sadb_x_policy_id                       |
     +---------------+---------------+---------------+---------------+
     |                     sadb_x_policy_priority                    |
    >+---------------+---------------+---------------+---------------+
     |    sadb_x_ipsecrequest_len    |    sadb_x_ipsecrequest_proto  |
     +---------------+---------------+---------------+---------------+
     |    ..._mode   |   ..._level   | sadb_x_ipsecrequest_reserved1 |
     +---------------+---------------+---------------+---------------+
     |                   sadb_x_ipsecrequest_reqid                   |
     +---------------+---------------+---------------+---------------+
     |                 sadb_x_ipsecrequest_reserved2                 |
     +---------------+---------------+---------------+---------------+
     ~     old source endpoint address         (64-bit aligned ...   ~
     +---------------+---------------+---------------+---------------+
     ~  old destination endpoint address       ... pair of sockaddr) ~
    >+---------------+---------------+---------------+---------------+
     |    sadb_x_ipsecrequest_len    |    sadb_x_ipsecrequest_proto  |
     +---------------+---------------+---------------+---------------+
     |    ..._mode   |   ..._level   | sadb_x_ipsecrequest_reserved1 |
     +---------------+---------------+---------------+---------------+
     |                   sadb_x_ipsecrequest_reqid                   |
     +---------------+---------------+---------------+---------------+
     |                 sadb_x_ipsecrequest_reserved2                 |
     +---------------+---------------+---------------+---------------+
     ~     new source endpoint address         (64-bit aligned ...   ~
     +---------------+---------------+---------------+---------------+



Ebalard & Decugis       Expires February 19, 2009              [Page 17]


Internet-Draft      PF_KEY Extension for Mobile IPv6         August 2008


     ~  new destination endpoint address       ... pair of sockaddr) ~
     +---------------+---------------+---------------+---------------+

   Following is a structure of PF_KEY base message header specified in
   [RFC2367].  A new message type for PF_KEY MIGRATE (i.e.,
   SADB_X_MIGRATE) should be specified in member sadb_msg_type.

              struct sadb_msg {
                      uint8_t         sadb_msg_version;
                      uint8_t         sadb_msg_type;
                      uint8_t         sadb_msg_errno;
                      uint8_t         sadb_msg_satype;
                      uint16_t        sadb_msg_len;
                      uint16_t        sadb_msg_reserved;
                      uint32_t        sadb_msg_seq;
                      uint32_t        sadb_msg_pid;
              };

   Following is the structure of key manager address extension header.
   SADB_X_EXT_KMADDRESS should be specified in sadb_x_kmaddress_exttype
   field.  It is followed by a pair of sockaddr structures holding
   respectively up-to-date local and remote address to be used by
   IKE_SA.  The pair is globally 64-bit aligned.

              struct sadb_x_kmaddress {
                      uint16_t        sadb_x_kmaddress_len;
                      uint16_t        sadb_x_kmaddress_exttype;
                      uint32_t        sadb_x_kmaddress_reserved;
              };
              /* sizeof(struct sadb_x_kmaddress) == 8 */
              /* Followed by two sockaddr (local and remote) */

   Following is a structure of address extension header specified in
   [RFC2367].  Upper layer protocol should be specified in member
   sadb_address_proto.

           struct sadb_address {
                   uint16_t        sadb_address_len;
                   uint16_t        sadb_address_exttype;
                   uint8_t         sadb_address_proto;
                   uint8_t         sadb_address_prefixlen;
                   uint16_t        sadb_address_reserved;
           };

   Following is a structure for holding attributes that are relevant to
   security policy, which is available on BSD and Linux IPsec
   implementations.  Direction of the target security policy should be
   specified in member sadb_x_policy_dir.



Ebalard & Decugis       Expires February 19, 2009              [Page 18]


Internet-Draft      PF_KEY Extension for Mobile IPv6         August 2008


           struct sadb_x_policy {
                   uint16_t        sadb_x_policy_len;
                   uint16_t        sadb_x_policy_exttype;
                   uint16_t        sadb_x_policy_type;
                   uint8_t         sadb_x_policy_dir;
                   uint8_t         sadb_x_policy_reserved;
                   uint32_t        sadb_x_policy_id;
                   uint32_t        sadb_x_policy_priority;
           };

   Following is a structure for holding attributes that are relevant to
   security association, which is available on BSD and Linux IPsec
   implementation.  IPsec protocol (ESP or AH) and mode of the target
   security association should be provided in member
   sadb_x_ipsecrequest_proto and sadb_x_ipsecrequest_mode, respectively.

           struct sadb_x_ipsecrequest {
                   uint16_t        sadb_x_ipsecrequest_len;
                   uint16_t        sadb_x_ipsecrequest_proto;
                   uint8_t         sadb_x_ipsecrequest_mode;
                   uint8_t         sadb_x_ipsecrequest_level;
                   uint16_t        sadb_x_ipsecrequest_reserved1;
                   uint32_t        sadb_x_ipsecrequest_reqid;
                   uint32_t        sadb_x_ipsecrequest_reserved2;
           };


Appendix B.  Acknowledgements

   Various people had contributed and were acknowledged in previous
   version of MIGRATE draft.  Because most of the text from previous
   draft has been kept in this document, those acknowledgements are
   still valid: Sebastien Decugis, Mitsuru Kanda, Kazunori Miyazawa,
   Tsuyoshi Momose Shoichi Sakane, Keiichi Shima, Noriaki Takamiya, and
   Hideaki Yoshifuji.

   Support of NAT Traversal was suggested by Kazunori Miyazawa.

   We would also like to acknowledge here the positive technical
   feedback from Shinta Sugimoto while extending his MIGRATE mechanism
   and also the work provided by people of USAGI (Masahide Nakamura,
   Shinta Sugimoto, Hideaki Yoshifuji, ...) on Linux kernel's Mobile
   IPv6 and IPsec stack.

   This document was generated by xml2rfc.






Ebalard & Decugis       Expires February 19, 2009              [Page 19]


Internet-Draft      PF_KEY Extension for Mobile IPv6         August 2008


Authors' Addresses

   Arnaud Ebalard
   EADS Innovation Works
   12, rue Pasteur - BP76
   Suresnes  92152
   France

   Phone: +33 1 46 97 30 28
   Email: arnaud.ebalard@eads.net


   Sebastien Decugis
   National Institute of Information and Communications Technology
   4-2-1, Nukui-Kitamachi,
   Koganei, Tokyo  184-8795
   Japan

   Email: sdecugis@hongo.wide.ad.jp
































Ebalard & Decugis       Expires February 19, 2009              [Page 20]


Internet-Draft      PF_KEY Extension for Mobile IPv6         August 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Ebalard & Decugis       Expires February 19, 2009              [Page 21]


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