[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04                                                
Mobility Extensions (MEXT)                                      B. Patil
Internet-Draft                                                     Nokia
Intended status: Standards Track                               D. Premec
Expires: January 14, 2010                                   Unaffiliated
                                                              C. Perkins
                                                                WiChorus
                                                           H. Tschofenig
                                                  Nokia Siemens Networks
                                                           July 13, 2009


Problems with the use of IPsec as the security protocol for Mobile IPv6
                draft-patil-mext-mip6issueswithipsec-01

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 January 14, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.




Patil, et al.           Expires January 14, 2010                [Page 1]


Internet-Draft        IPsec issues with Mobile IPv6            July 2009


Abstract

   Mobile IPv6 as specified in RFC3775 relies on IPsec for security.  An
   IPsec SA between the mobile node and the home agent provides security
   for the mobility signaling.  Use of IPsec for securing the data
   traffic between the mobile node and home agent is optional.  This
   document analyses the implications of the design decision to mandate
   IPsec as the default security protocol for Mobile IPv6 and
   consequently Dual-stack Mobile IPv6 and recommends revisiting this
   decision in view of the experience gained from implementation and
   adoption in other standards bodies.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology and Abbreviations  . . . . . . . . . . . . . . . .  3
   3.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  4
   5.  General issues with the use of IPsec for MIP6 security . . . .  6
   6.  Implementation Issues with IPsec . . . . . . . . . . . . . . .  8
     6.1.  Triggering IKEv2 on the MN . . . . . . . . . . . . . . . .  8
     6.2.  Instructing IKEv2 to ask for the MN HoA/prefix . . . . . .  9
     6.3.  Providing the MN prefix to the IKEv2 daemon  . . . . . . .  9
     6.4.  Registering the MN's FQDN in DNS . . . . . . . . . . . . .  9
     6.5.  Providing the Home Network Prefix to the MIP6
           application  . . . . . . . . . . . . . . . . . . . . . . .  9
     6.6.  SPD Entry for the HoA on the MN side . . . . . . . . . . . 10
     6.7.  SPD Entry for the HoA on the HA side . . . . . . . . . . . 10
     6.8.  The K bit  . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.9.  UDP encapsulation of DSMIP6 signaling  . . . . . . . . . . 11
     6.10. Transport mode IPsec SAs and NATs  . . . . . . . . . . . . 11
   7.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     11.2. Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14











Patil, et al.           Expires January 14, 2010                [Page 2]


Internet-Draft        IPsec issues with Mobile IPv6            July 2009


1.  Introduction

   Mobile IPv6 as specified in RFC3775 [RFC3775] requires an IPsec
   security association between the mobile node (MN) and home agent
   (HA).  The IPsec SA protects the mobility signaling messages between
   the MN and HA.  The user data may be optionally protected by the
   IPsec SA but is not required.

   The use of IPsec and IKE (v1 and v2) with Mobile IPv6 are specified
   in RFCs 3776 [RFC3776] and 4877 [RFC4877].  The Mobile IP and MIP6
   working groups in the IETF chose to mandate IPsec as the default
   security protocol for Mobile IPv6 based on various criteria and
   lengthy discussions that occured between the years 2000 and 2004.
   Implementation experience with Mobile IPv6 and the security variants
   with which it has been specified in some SDOs indicates a need to
   revisit the design choice for MIP6 signaling security.  The analysis
   and recommendation to revisit the security protocol architecture for
   MIP6 should not be interpreted as a recommendation for Authentication
   Protocol for Mobile IPv6 [RFC4285].  The objective is to highlight
   the misfit of IPsec and IKEv2 as the security protocol for MIP6 and
   hence the need for considering alternatives.


2.  Terminology and Abbreviations

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

   This document refers to [RFC3775][RFC4877] for terminology.


3.  Background

   IP mobility support in IPv6 was considered to be an integral feature
   of the IPv6 stack based on the experience gained from developing
   mobility support for IPv4.  The design of Mobile IPv6 was worked on
   by the Mobile IP WG in the late 90s and by the MIP6 WG until its
   publication as [RFC3775] in 2004.

   IPsec [RFC4301] was also intended to be a default component of the
   IPv6 stack and was the preferred protocol choice for use by any other
   IPv6 protocol that needed security.  Rather than design security into
   every protocol feature, the intent was to reuse a well-defined
   security protocol to meet the security needs.  Hence Mobile IPv6 has
   been designed with the security architecture relying on IPsec.

   The Mobile IPv6 specification [RFC3775] was published along with the



Patil, et al.           Expires January 14, 2010                [Page 3]


Internet-Draft        IPsec issues with Mobile IPv6            July 2009


   companion specification "Using IPsec to Protect Mobile IPv6 Signaling
   Between Mobile Nodes and Home Agents", [RFC3776].  The establishment
   of the IPsec SA between the MN and HA as per RFC 3776 is based on the
   use of IKE.  The use of IKE in the context of Mobile IPv6 for IPsec
   SA establishment did not gain traction because of factors such as
   complexity of IKE and the IETF transitioning to IKEv2.  The MIP6 WG
   completed the specification, Mobile IPv6 Operation with IKEv2 and the
   Revised IPsec Architecture [RFC4877] in April 2007.  This [RFC4877]
   is considered as the default security protocol solution for MIP6 and
   updates [RFC3776].


4.  Problem Statement

   Mobile IPv6 is encumbered by its reliance on IPsec [RFC4301] from an
   implementation and deployment perspective.  As a protocol solution
   for host based mobility, MIP6 can be simpler without the IPsec
   baggage.  The issues with IPsec are even more exacerbated in the case
   of dual-stack MIP6 [RFC5555].

   IPsec SAs between the MN and HA are established either manually or
   via the use of IKEv2 [RFC4306].  Manual SA configuration is not a
   scalable solution and hence MIP6 hosts and Home agents rely on IKEv2
   for establishing dynamically IPsec SAs.  As a result MIP6 depends on
   the existence of IPsec and IKEv2 for successful operation.

   IPsec is unable to provide security protection for MIP6 in a
   transparent way, and numerous interactions between the host's
   security subsystems and the MIP6 application are needed in the course
   of the regular operation of the MIP6 application.  Besides requiring
   an extensive communications channel between the security subsystems
   and the MIP6 application, those interactions often also require
   modification of the MNs security subsystems code.  The situation
   today is such that the communications channel between the IPsec
   subsystems and the MIP6 application is non existent and this is
   generally true for most of the commercially available platforms.
   Even if such a channel were to be available, there does not exist a
   standardized protocol over that channel which would enable the MIP6
   application to communicate with the security modules in a non-
   implementation specific way.

   Considering a third party application developer who would like to
   provide a MIP6 application for a particular platform, the need for
   numerous interactions with the IPsec subsystem and the unavailability
   of the standardized communications channel through which such
   interactions could take place is a major obstacle to the
   implementation of the mobility protocol.  Without such a
   communication channel being available it is not possible to implement



Patil, et al.           Expires January 14, 2010                [Page 4]


Internet-Draft        IPsec issues with Mobile IPv6            July 2009


   a MIP6 application as a third party developer.

   Even if the platform would provide such a communication interface for
   the MIP6 daemon, this is still insufficient as the MIP6 protocol
   standardized today [RFC3775] requires numerous changes to the host's
   IPsec and IKEv2 implementation.  This document enumerates various
   implementation issues related to the interactions between the MIP6
   application and the host's security subsystems.

   An argument can be made that the MIP6 application itself should
   provide the required changes to the IPsec subsystems of the platform
   (maybe in the form of patches).  While this is possible at least for
   some open source platforms to provide modifications to the host's
   IPsec implementation as well as the key management application(s),
   this is still an issue for several reasons:

   o  Target platform could be a commercial platform for which no source
      code is available.
   o  If the MIP6 application were to patch the IPsec subsystems, then
      multiple MIP6 applications from different developers would
      implement it in different ways, which would inevitably lead to
      variations and problems with interoperability at a minimum, for
      instance when the user tries to install several MIP6 applications
      it is difficult to determine which one is the best suited for his/
      her needs.
   o  Key management daemons are usually provided as third party
      software for which no source code may be available, even if the
      platform itself is available as open source.
   o  Even if the MIP6 application developer would be willing to provide
      patches for the key management daemon to make it work with his
      MIP6 application, how would the MIP6 application developer know
      which of the several available key management daemons the user is
      running?
   o  Each application would be able to work only with a single key
      management daemon, namely the one for which the MIP6 application
      provides the patches.  The user may be running another key
      management daemon and may be unwilling to change its daemon to the
      one that comes as part of the MIP6 application.
   o  Patches for the IPsec part in the kernel and the key management
      daemon would typically be valid only for the particular version of
      the kernel and the key management daemon for which they were
      written.  This might prevent the user from upgrading the platform
      or applying OS security patches that are provided as part of the
      regular platform maintenance since this would in all probability
      make the MIP6 application defunct.
   o  Modifying the security subsystems by a third party is a security
      issue and users are generally advised to refrain from allowing the
      security subsystems to be modified in any way.



Patil, et al.           Expires January 14, 2010                [Page 5]


Internet-Draft        IPsec issues with Mobile IPv6            July 2009


   o  The developer may not have the knowledge or the time to modify the
      platform's IPsec subsystems, although it might be perfectly
      capable to deliver the MIP6 application itself.
   o  There could be copyright issues as well that would prevent
      modifications of the platform's security subsystems or the
      delivery of the modifications by the third party.
   o  Even if the MIP6 application developer is able to come up with the
      necessary patches for the security subsystem, it is not realistic
      to expect the prospective user of MIPv6 to first patch the kernel
      and the key management daemons before using the MIPv6 service.

   The above discussion shows why it is unrealistic to expect that the
   MIP6 application could provide the needed modifications to the IPsec
   subsystems of the host.  Section 6 presents a more technical
   discussion of various implementation issues related to the
   interworking between the MIP6 application and the IPsec/key
   management modules.

   The problem in a nutshell for MIP6 is the dependence on IPsec and
   IKEv2 for successful operation.


5.  General issues with the use of IPsec for MIP6 security

   This section captures several issues with the use of IPsec by MIP6.

   (1)  The design of Mobile IPv6 emphasized the reuse of IPv6 features
        such as IPsec.  IPsec for IPv4 was a bolt-on solution.  With the
        increasing need for security, IPv6 designers chose to
        incorporate IPsec as a default feature.  There existed an
        assumption in the MIP6 working group that every IPv6 host would
        have IPsec capability as a standard feature.  While this is true
        in many host implementations today, the existence of IPsec in
        every IPv6 stack is not a given.  Hence a host which needs to
        implement Mobile IPv6 must ensure that IPsec and IKEv2 are also
        available.  As a result of this dependence, MIP6 is no longer a
        standalone host-based mobility protocol.  A good example of a
        host based mobility protocol that works as a self-sufficient
        module is Mobile IPv4 [RFC3344].  The security associated with
        MIP4 signaling is integrated into the protocol itself.  MIP4 has
        been successfully deployed on a large scale in several networks.
   (2)  IPsec use in most hosts is generally for the purpose of VPN
        connectivity to enterprises.  It has not evolved into a generic
        security protocol that can be used by Mobile IPv6 easily.  While
        RFC4877 does specify the details which enable only the MIP6
        signaling to be encapsulated with IPsec, the general method of
        IPsec usage has been such that all traffic between a host and
        the IPsec gateway is carried via the tunnel.  Selective



Patil, et al.           Expires January 14, 2010                [Page 6]


Internet-Draft        IPsec issues with Mobile IPv6            July 2009


        application of IPsec to protocols is not the norm.  Use of IPsec
        with Mobile IPv6 requires configuration which in many cases is
        not easily done because of reasons such as enterprise
        environments preventing changes to IPsec policies or other.
   (3)  A MIP6 home agent is one end of the IPsec SA in a many-to-one
        relationship.  A MIP6 HA may support a very large number of
        mobile nodes which could be in the hundreds of thousands to
        millions.  The ability to terminate a large number of IPsec SAs
        (millions) requires signifiant hardware and platform capability.
        The cost issues of such an HA are detrimental and hence act as a
        barrier to deployment.
   (4)  The implementation complexity of Mobile IPv6 is greatly
        increased because of the interaction with IPsec and IKEv2.  A
        standalone MIP6 protocol is easier to implement and deploy (such
        as MIP4 [RFC3344]).  The complexity of the protocol
        implementation is even more so in the case of Dual stack MIP6
        [RFC5555].
   (5)  IPsec and IKEv2 are not implemented or available by default in
        every IPv6 or dual stack host.  Mobile IPv6 support on such
        devices is not an option.  Many low-end cellular hosts have IP
        stacks.  The need for IPsec and IKEv2 in these devices is not
        important whereas mobility support is needed in many cases.  A
        simpler security protocol than the use of IPsec/IKEv2 would make
        MIP6 much more attractive to implement and deploy.
   (6)  [RFC4877] which specifies the use of IKEv2 and IPsec with Mobile
        IPv6 essentially results in a variant of IPsec which is specific
        to Mobile IP.  Hence this results in added complexity to
        implementations.
   (7)  Mobile IPv6 needs to be capable of being deployed in situations
        where alternative security mechanisms are already well-
        understood by the network administration.  It should be possible
        to enable Mobile IPv6 to work in situations where alternative
        security mechanisms already supply the necessary authentication
        and privacy.
   (8)  IPsec has been successfully applied to VPN and other
        infrastructure operations, but less so for general end-to-end
        applications.  Thus, the granularity for selectors was
        originally not at all sufficient for Mobile IPv6.
   (9)  The way that the IPsec code sits in the usual kernel, and the
        access mechanisms for the SA database, are not very convenient
        for use by straightforward implementations of Mobile IPv6.
        Unusual calling sequences and parameter passing seems to be
        required on many platforms.
   (10) In certain environments the use of IPsec and IKEv2 for
        establishing the SA is considered as an overhead.  Bandwidth
        constrained links such as cellular networks and air interfaces
        which are in the licensed spectrum tend to be optimized for user
        traffic.  MIP6 signaling with the IPsec overhead and the IKEv2



Patil, et al.           Expires January 14, 2010                [Page 7]


Internet-Draft        IPsec issues with Mobile IPv6            July 2009


        messages are viewed negatively.  It is more acceptable to have
        signaling without IPsec encapsulation.

   The issues listed above can be attributed as some of the causes for
   MIP6 not being implemented widely.


6.  Implementation Issues with IPsec

6.1.  Triggering IKEv2 on the MN

   When the MIP6 application is invoked on the MN, as part of the
   initialization steps it is expected to install the appropriate SPD
   entries for protecting the mobility management signaling.  Creation
   of the SPD entry works fine assuming that the MN is statically
   preconfigured with the HoA information since the HoA address is
   needed to create the SPD entries.  Once the SPD entries are created,
   the MIP6 application generates the BU message and sends it via the
   socket.  Based on the previously installed SPD entry the IP stack
   detects that the BU message needs IPsec protection and since there is
   no appropriate IPsec SA available, the OS kernel triggers the key
   management daemon to establish the needed IPsec SA.

   Things are not that straightforward when the HoA is assigned
   dynamically.  MIP6 allows the MN to obtain the HoA dynamically during
   the establishment of the initial IPsec SA with the HA [RFC4877] and
   in this case the HoA is provided in the CONF IKEv2 payload.  How is
   the key management daemon triggered to establish the IPsec SA with
   the HA in this case?  Normally there should be an SPD entry in the
   SPD with the HoA address as part of the selector and the outgoing BU
   message would be matched against that entry and this would trigger
   the kernel to request the establishment of the IPsec SA.  But the
   MIP6 application is not able to install the appropriate SPD entry nor
   to generate the BU message since it doesn't have yet the HoA that is
   needed for this, the HoA becomes available only later as part of the
   IPsec SA establishment.  So this is sort of a chicken and egg
   problem: the HoA is needed to trigger the establishment of the IPsec
   SAs, but the HoA is not available prior to the IPsec SA being
   established.

   The solution to this issue could be an out-of-band communication
   channel between the MIP6 application and the key management daemon
   through which the MIP6 application could request the establishment of
   the appropriate IPsec SA from the key management daemon without
   having to install the appropriate SPD entries and generate the BU
   message.





Patil, et al.           Expires January 14, 2010                [Page 8]


Internet-Draft        IPsec issues with Mobile IPv6            July 2009


6.2.  Instructing IKEv2 to ask for the MN HoA/prefix

   In case of dynamic HoA assignment, the MIP6 application needs to
   instruct the key management daemon to request the HoA information
   from the HA.  The MIP6 application must be able to tell whether it
   would like to get the complete address or only the prefix [RFC5026]
   from the HA, and also whether it would like to get the IPv4 HoA as
   part of the IKEv2 exchange.  This requires an interface between the
   MIP6 application and the key management daemon.

6.3.  Providing the MN prefix to the IKEv2 daemon

   When the key management daemon on the HA side receives a request from
   the initiator to allocate the MIP6_HOME_PREFIX it needs to get the
   prefix from the MIP6 daemon running on the HA.  Therefore there must
   be a communication channel between the key management daemon and the
   MIP6 application through which the key management daemon could
   request the HoA/prefix information.  Further, when assigning the
   prefix, the MIP6 application needs to create state and save the
   assigned address information and associate it with the MN which
   created the IPsec SA.  So this looks like at this point there is a
   need to create the BCE in a some type of a "larval" state as a place
   where to save this information on the HA side.

   Request to assign an address (IPv6 and/or IPv4) via the CONF payload
   raises an additional concern, namely, how does the key management
   daemon know that it needs to obtain the address from the MIP6
   application?  A generic key management daemon would by default have
   some other means to provide the addresses in the CONF payload without
   consulting the MIP6 application, so there must be some method to tell
   the key management daemon that it should request the addresses from
   the MIP6 application.  The author is not aware of any such method
   being available currently.

6.4.  Registering the MN's FQDN in DNS

   [RFC4877] allows the HA to register the MN's FQDN in the DNS.  In
   this case the MN must provide the FQDN in the IDi payload in the
   IKE_AUTH step of the IKEv2 exchange.  Consequently, there must be
   some interface between the key management daemon and the MIP6
   application on the HA side through which the FQDN could be made
   available to the MIP6 application so that it can register the FQDN in
   DNS.

6.5.  Providing the Home Network Prefix to the MIP6 application

   When the key management daemon on the MN side obtains the home
   network prefix information from the HA, it needs to relay this



Patil, et al.           Expires January 14, 2010                [Page 9]


Internet-Draft        IPsec issues with Mobile IPv6            July 2009


   information to the MIP6 application.  This again requires a
   communication channel between the key management daemon and the MIP6
   application.

6.6.  SPD Entry for the HoA on the MN side

   Once the MIP6 application on the MN obtains the HoA (either assigned
   via the CONF IKEv2 payload [RFC4877] or autoconfigured from the
   MIP6_HOME_PREFIX [RFC5026]), the appropriate SPD entries need to be
   created in the SPD.  Some key management daemons may require that
   they have full control of the SPD.  In such cases the MIP6
   application should not create the SPD entries by itself as this might
   confuse the MIP6 daemon and cause inconsistent state.  Instead, the
   MIP6 application would need to instruct the key management daemon to
   create the appropriate SPD entries.  So depending on the expectations
   of the key management daemon, the MIP6 application should either
   instruct the key management daemon to create the SPD entries or the
   MIP6 application should create them by itself at this point.

   If the policy requires protection of the data traffic the SPD entries
   for the data traffic would also need to be created at this point.

6.7.  SPD Entry for the HoA on the HA side

   The creation of the SPD entry on the HA side for protecting the MN's
   mobility signaling is similar to what is happening on the MN side and
   is described in the previous section.  As soon as the HA assigns an
   HoA it may proceed with the creation of the appropriate SPD entry.
   The SPD entries for protecting the data traffic should also be
   created at this time.

   However, the issue gets more complicated in the case where the HA
   provides the prefix to the MN and the MN autoconfigures the HoA.  In
   this case neither the key management daemon nor the MIP6 application
   on the HA are aware of the MN's autoconfigured HoA so neither of them
   is in a position to install an appropriate SPD entry during (or
   immediately after) the IKEv2 exchange.  Even worse, since the
   autoconfigured MN address is not known on the HA side it is not clear
   what is the contents of the TSi and TSr payloads in the final
   IKE_AUTH message sent by the HA.  It is unclear whether or not the SA
   for protecting the MN's mobility signaling gets established at all in
   such a situation.

   TBD: verify whether this is really a problem...







Patil, et al.           Expires January 14, 2010               [Page 10]


Internet-Draft        IPsec issues with Mobile IPv6            July 2009


6.8.  The K bit

   The K bit [RFC3775] requires an interface between the IPsec subsystem
   and the MIP6 application that is not available today, at least not in
   a standardized form.  Such an interface that would enable the support
   for the K bit has been proposed before and additional information how
   it might look like is available in [I-D.sugimoto-mip6-pfkey-migrate]
   and [I-D.ebalard-mext-pfkey-enhanced-migrate].  However, those
   proposals were not standardized and as such there is no publicly
   available interface specification that could be used by the third
   party MIP6 application developers to invoke the key management daemon
   and IPsec kernel.  Note also that the MIP6 application must have a
   detailed knowledge about the established IPsec SAs (complete SPD
   entries, old and new tunnel end points) in order to be able to
   indicate to the key management daemon which SAs needs to be updated,
   which is not in the spirit of the original IPsec intention to provide
   security to the applications in a transparent manner.

6.9.  UDP encapsulation of DSMIP6 signaling

   The DSMIP6 specification enables the MIP6 enabled MN to roam in IPv4
   networks [RFC5555].  To cope with NATs the DSMIP6 specification
   introduces a UDP encapsulation feature for the MIP6 signaling
   messages as well as for the data traffic.  The UDP encapsulation
   feature requires very tight coupling between the IPsec subsystems and
   the MIP6 application.

   To send the BU message the MIP6 daemon first needs to generate the BU
   message and then hand it over to the IPsec subsystem which adds the
   transport mode ESP protection.  Then in the next step the message
   must go back from the kernel to the MIP6 daemon in the user space
   which adds DSMIP6 UDP encapsulation and then the packet is finally
   sent out on the interface.

   When the UDP encapsulated Binding Acknowledgment message is received
   on the MN side, it is first delivered to the MIP6 application which
   strips the UDP header and then somehow hands over the stripped
   message to the kernel's IPsec subsystem.  The IPsec subsystems takes
   care of the transport mode ESP protecting the BU message and after
   removing the ESP header delivers the BU message back to the MIP6
   application.

6.10.  Transport mode IPsec SAs and NATs

   In order to establish an IPsec SA in the case of DSMIP6 when the MN
   is behind a NAT, it is required to use transport mode SAs only.
   Implementation experience at least has shown that it is not easily
   done and the operation itself of establishing the IPsec SA is flaky



Patil, et al.           Expires January 14, 2010               [Page 11]


Internet-Draft        IPsec issues with Mobile IPv6            July 2009


   at best.


7.  Conclusion

   Examples in Section 6 show that there is a need for an extensive
   communication between the MIP6 application and the IPsec subsystem on
   the host.  Standardizing such communication channel and having it
   available in a commercial OS implementations is not a realistic
   proposal in any practical time frame.  On the technical side, this is
   due to the fact that the IPsec is usually provided as part of the OS
   kernel and it is always difficult to convince the OS vendor to change
   the kernel and in particular the security related subsystems.  The
   other difficulty is that the key management is usually provided as
   the user space service and as such there are multiple key management
   daemons available.  Convincing vendors of various key management
   daemons to provide a unified or standardized communication channel
   for the MIP6 application might prove equally difficult and is not a
   realistic option either.  Besides the technical reasons, there are
   also other non-technical reasons of business or political nature why
   such proposals would be unrealistic.

   Therefore this draft recommends that an alternate security framework
   be considered for MIP6.  This alternate mechanism should be self
   contained so that it can be developed and delivered as part of the
   MIP6 application itself (from an implementation perspective analogous
   to the way web browsers handle security today).  This would enable
   third party developers that have no access or are otherwise not in a
   position to change the IPsec code of the platform they are developing
   for to come up with a self contained and working MIP6 application.
   Such alternative security mechanisms would remove one of the major
   impediments, i.e the interactions with IPsec - why it is so difficult
   today to implement a working MIP6 application.  This would foster the
   diversity of the MIP6 solutions and should therefore have beneficial
   effects on the availability of MIP6 solutions and promote the
   adoption of MIP6 in general.

   In order to make the Mobile IPv6 protocol a solution that is easy to
   implement and available in even low-end devices, it is necessary to
   simplify the protocol.  The design or the security architecture for
   MIP6 needs to be revisited and a solution that simplifies the
   implementability of the protocol considered.  The implementation
   experience shows that a working solution of Mobile IPv6 is possible
   to build.  However it is not easily done.







Patil, et al.           Expires January 14, 2010               [Page 12]


Internet-Draft        IPsec issues with Mobile IPv6            July 2009


8.  Security Considerations

   This I-D discusses the security architecture of Mobile IPv6 which is
   based on IPsec.  The dependency on IPsec for security of MIP6
   signaling is a detriment to the protocol implementation and
   deployment.  Hence the current security architecture needs to be
   reconsidered.

   The experience gained over the last few years indicates that IPsec
   cannot necessarily be used as a generic solution for security.  The
   design choice made for MIP6 in the initial stages no longer are valid
   and is hampering the implementation and use.


9.  IANA Considerations

   This document does not have any information which requires IANA
   review.


10.  Acknowledgements

   Jouni Korhonen would like to point out the importance of sustained
   supply of caffeine rich coffee when doing IETF work.  Authors would
   also like to recognize Satyabrata Sahu, NK Garg, Sandeep Minocha and
   Harsh Verma for working on the implementation.


11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC4877]  Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
              IKEv2 and the Revised IPsec Architecture", RFC 4877,
              April 2007.

   [RFC5026]  Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
              Bootstrapping in Split Scenario", RFC 5026, October 2007.



Patil, et al.           Expires January 14, 2010               [Page 13]


Internet-Draft        IPsec issues with Mobile IPv6            July 2009


   [RFC5555]  Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
              Routers", RFC 5555, June 2009.

11.2.  Informative References

   [I-D.ebalard-mext-pfkey-enhanced-migrate]
              Ebalard, A. and S. Decugis, "PF_KEY Extension as an
              Interface between Mobile IPv6 and IPsec/IKE",
              draft-ebalard-mext-pfkey-enhanced-migrate-00 (work in
              progress), August 2008.

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

   [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
              August 2002.

   [RFC4285]  Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
              Chowdhury, "Authentication Protocol for Mobile IPv6",
              RFC 4285, January 2006.

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


Authors' Addresses

   Basavaraj Patil
   Nokia
   6021 Connection Drive
   Irving,  TX  75039
   USA

   Email: basavaraj.patil@nokia.com











Patil, et al.           Expires January 14, 2010               [Page 14]


Internet-Draft        IPsec issues with Mobile IPv6            July 2009


   Domagoj Premec
   Unaffiliated
   Heinzelova 70a
   Zagreb,   10000
   CROATIA

   Phone:
   Fax:
   Email: domagoj.premec.ext@gmail.com


   Charles Perkins
   WiChorus
   3590 N. 1st Street, Suite 300
   San Jose, CA  95134
   USA

   Email: charliep@wichorus.com


   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600
   Finland

   Phone: +358 (50) 4871445
   Email: Hannes.Tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at






















Patil, et al.           Expires January 14, 2010               [Page 15]