[MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01

[[e-mail] (Arnaud Ebalard)]

Hi,

below is a review of draft-patil-mext-mip6issueswithipsec-01.

> 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

You should introduce the SDOs here i.e. have "some SDOs (XXX, YYY,
...). They are *never* cited in the whole document. The issues common
and specific to each of those about IPsec/IKE should be summarized in
the document.

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

Optional use of IKE. Nonetheless, I agree that using IKE is the only
possible way to go when you need to scale.

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

I agree.

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

Sorry, but the design decisions taken for DSMIPv6 make it the way it
is. You cannot blame IPsec/IKE for IPv4/NAT issues. The problem with
DS-MIPv6 is that it does not provide IPv6 connectivity for the MN that
could be used transparently by the stack (Teredo does that). When the
protocol has been designed, it has been decided to open the door to
IPv4, which let the NAT issue enter. Due to that decision, the
difficulties of IPv4/NAT have also impacted the use of DSMIPv6 with
IPsec/IKE.

I would be interested to have the honest opinion of the main
contributors of RFC 5555 on that topic.

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

yes.

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

For common scenario, MIGRATE/KMADDRESS solution is sufficient. This
requires small changes to the IPsec stack, the IKE daemon and the MIPv6
module. After 3776, it is my feeling that MEXT documents have slowly
shifted towards tighter relationships between the MIPv6 module and the
IKE (address assignment) module to the point that it would be difficult
today to provide all the functionalities pushed so far without having a
common MIPv6/IKE module (or at least complex interactions between
those).

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

Well, I expect all possible L3 solutions to require changes to the
security subsystems to support MIPv6 needs but I'd like to be proven
wrong.

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

The sentence is correct.

Well, I won't advocate for other platforms but at least Linux has that
now, which proves it is feasible:

 - Upstream Kernel supports full MIGRATE/KMADDRESS since 2.6.28. Current
   is 2.6.30.
 - racoon (IKEv1) has support for MIGRATE/KMADDRESS for a while now
 - StrongSwan developers have added support for MIGRATE/KMADDRESS to
   Charon, their IKEv2 daemon.
 - patches exist for racoon2

I can't say about *BSD platform.

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

Well, I already pointed that and even provided follow-up work for
MIGRATE/KMADDRESS but this was considered out of scope for the
WG. Having that work done in the context of ipsecme WG was not possible 
either.

But thanks for stressing that point.

>    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
>    a MIP6 application as a third party developer.

3 main possible solutions:

  - standardize the interface
  - make MIPv6 module and IKEv2 module a common module (as
    progressively expected by MEXT documents published after 3775)
  - give up on the use of IPsec/IKE

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

I respectfully disagree, not with the various points above, but with the
way you interpret them. Vendors implement features in their products
based on business case and possibly the availability of a standard. If
open source product already have the feature, I think may indicate the
issue is not the technical feasibility ...

>From a discussion I had with some MS engineers after they unleashed the
details on Vista's IPv6 stack, asking them for the reasons why it had no
MIPv6 support: no business case and no standard interface to secure
it.

There are some people working for vendors (Cisco, ...) on MEXT so they
can probably provide valuable comments on the reason why they don't have
support for IPsec/IKE w/ MIPv6. Vendors that have support could also
comment on how they did it and why.

I think the points you give above shoud be interpreted the following
way: to be easiliy implemented on a *commercial* platform without
interactions with the associated vendors (implying business cases and
money), it would be easier for MIPv6 to be self contained and with the
least possible interactions with the networking stack, security stack
and other third party applications (like IKE module). Hence a possible
reason not to rely on IPsec and IKE. But this is only one side of the
coin, i.e. there are drawbacks in taking such a path: how do you provide
security? from scratch or based on another building block? can you
support protection of IP data? What interface do you provide to users to
enable the various protection modes? Does the solution target the IPv6
internet or only a small subset of it?

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

3775 and 4877 provide a *generic* solution for the Internet environment,
i.e. common platforms and systems. As you write, "[IPsec as a default
feature] is true in many host implementations today". If specific
systems have specific needs which do not fit with a generic solution,
then they need a specific solution. If they are so specific, they may
simply not be in the scope of MIPv6 generic solution.

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

Section 5.5 (Privacy) of RFC 3344 has the following:

   Users who have sensitive data that they do not wish others to see
   should use mechanisms outside the scope of this document (such as
   encryption) to provide appropriate protection.  Users concerned about
   traffic analysis should consider appropriate use of link encryption.

The difference is that MIPv6 tries and address that instead of leaving
the user alone.

With MIPv4, extensions of the protocol to support full security have
(what I consider) funny drawings like the following (RFC 5265):

      .------------------------------------------------------- -
      ! IP      ! IP      ! ESP ! IP       ! IP     ! user      \
      !  co-CoA !  x-HoA  !     !  VPN-TIA !  i-HoA ! protocol../
      !  x-HA   !  VPN-GW !     !  i-HA    !  CN    !           \
      `------------------------------------------------------- -
         - - -----------------.
        \..user     ! ESP     !
        /  protocol ! trailer !
        \           !         !
         - - -----------------'

It was decided to make MIPv6 compatible with IPsec/IKE (and use those
for the security). This allows more from a security standpoint but
requires more initial investment. That initial investment seems to be
considered too high a price for environments with different assumptions
or existing security mechanisms. 

>         MIP4 signaling is integrated into the protocol itself.  MIP4 has
>         been successfully deployed on a large scale in several networks.

Can you describe the assumptions about those network? Do they come with
link layer security for instance? Can a user of those networks move to
the Starbuck at the corner and use the wifi there without the need to
care about how its data are protected on that foreign network?

RFC 3775 Introduction starts with: "This document specifies a protocol
which allows nodes to remain reachable while moving around in the IPv6
Internet"

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

Can some vendor comment on that. Do we agree that the amount of traffic
is not the issue but the initial IKE negotiation and the number of SA
might be?

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

MIPv6 and MIPv4 do not have equivalent feature security-wise. MIPv6 is
certainly more complex on that aspect than MIPv4 but it allows
more. Moreover, it builds (even if some bits may be missing
interface-wise) on existing and mature protocol (not speaking about
IKEv2 yet ;-) ) which prevents reinventing the wheel.

>    (5)  IPsec and IKEv2 are not implemented or available by default in
>         every IPv6 or dual stack host.

Can you list some (2 or 3) systems that are of common use today and that
do not have that?

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

I may be wrong but the way I see it is that current trend if for
cellular devices to come with complete systems today: what does the
iPhone runs? Nokia is currently shifting towards Linux based solutions
(ofono, maemo, ...)? Many phones runs Windows Mobile too, ...

If you consider the previous devices and most of the laptop (99% of
the latter running Mac OS X, Linux or Windows), I think you have the
initial targets MIPv6 is trying to provide mobility for. Or am I missing
your point?

>         A simpler security protocol than the use of IPsec/IKEv2 would make
>         MIP6 much more attractive to implement and deploy.

Those sepecific devices may need a specific solution. I agree on that.

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

No. IPsec stack and IKE daemon may already have support for MOBIKE which
does exactly what we need. The only difference is that the signaling
goes through the IKE channel. With MIPv6, signaling is MIPv6 one
(BU/BA). In all cases, extending the IPsec stack to support MIPv6 is
light. Same for IKE. 

>         Hence this results in added complexity to implementations.

No. Compare the small required extensions (MIGRATE/KMADRESS is short to
read) with what it would cost to provide the same amount of features
(protecting signaling and possibly data) but by designing and
implementing a specific protocol in the MIPv6 module.

IMHO, a simple extension cost less than a complete new design. And
considering you are speaking about a security solution, designing from
ground a new security solution for your own need is starting looking for
trouble, all the more if you are trying to provide a L3 security
solution, i.e. trying to compete with IPsec/IKE.

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

Agree.

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

Yes. The use of new IPsec architecture and IKEv2 in 4877 solved that
issue.

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

Yes. Standardizing or at least providing some guidance on that would be
helpful.

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

Future Aeronautical environments have those constraints. Nonetheless,
they will rely on IPsec and IKEv2 (see ICAO 9896 document).

>         MIP6 signaling with the IPsec overhead and the IKEv2 messages
>         are viewed negatively.  It is more acceptable to have
>         signaling without IPsec encapsulation.

Well, a security mechanism to protect MIPv6 signaling will certainly
require some bits in each packet. Let's compare that to what ESP adds to
be fair.

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

Right.

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

Thanks for asking that question about section 9 of RFC 4877. I am on
your side here.

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

+1

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

yes. Or as it appears to be the underlying assumption a merged MIPv6/IKE
module (I don't advocate for that).

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

If the feature is needed, yes.

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

me neither.

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

Can you point a specific section of RFC 4877. I fail to find where this
feature is discussed.

> 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
>    information to the MIP6 application.  This again requires a
>    communication channel between the key management daemon and the MIP6
>    application.

yes.

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

StrongSwan developers hit that issue when implementing
MIGRATE/KMADDRESS because UMIP (the Mobile IPv6 daemon for Linux)
handles all the policies. It just let the IKE daemon perform the SA nego
for those policies. I think this is handled via the installpolicy=no in
the configuration described on the following page:

   http://wiki.strongswan.org/wiki/strongswan/MobileNodeSetup

For racoon (IKEv1 daemon), this was not an issue: racoon monitors the
in-kernel SPD.

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

yes.

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

yes.


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

Another reason for having the Mobile IPv6 daemons interact with the SPD
directly.

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

the latter is a follow-up of the former. Implementation feedback
provided by the implementation of the former showed that
SADB_X_EXT_PACKET mechanism had drawbacks. Hence the extension to use
KMADDRESS.

[I-D.ebalard-mext-pfkey-enhanced-migrate] is currently available as a
draft and implemented. I had discussion with the chairs to go further in
the context of MEXT but the WG is not supposed to work on that kind of
item. 

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

Well, this is the work of the MIPv6 module to perform that, i.e. keep
that information updated. 

> 6.9.  UDP encapsulation of DSMIP6 signaling

I will not comment on DSMIPv6 because, IMHO, the problem of DSMIPv6 is
NAT, not IPsec/IKE. But I agree that DSMIPv6 is way too complex on many
aspects, including its relationships with IPsec/IKE.

Personally, even if one can argue on the associated drawbacks of the
solution in term of encapsultation (IPv4/UDP/IPv6/ESP/IPv6/TCP/HTTP for
common traffic exchanged with my HA, which mean I lose at least 24 bytes
of MTU) and some other aspects (I don't have an IPv4 HoA), I use Teredo:
it has been designed to be smart about NAT and only that, it is good at
it and provides a very good abstraction: a usable IPv6 link. My MIPv6
module is not IPv4 -aware and my IKE daemon is compiled with
--disable-natt ;-)

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

If you don't need the HoA assignment and additional features provided in
some section of 4877 and 5026, "extensive" is a bit too much.

>  Standardizing such communication channel and having it
>    available in a commercial OS implementations is not a realistic
>    proposal in any practical time frame.

Please, site names of vendors and OS, not in the draft but on the
list. This is looks like a vendor issue more than anything else. I don't
like the logic but if you have a business case for them then previous
issue vanishes.

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

You don't have to convince vendors. If the protocol is available
(documented) and the feature is worth implementing for their clients, I
don't see why they would refuse if other vendors would agree.

>  Besides the technical reasons, there are
>    also other non-technical reasons of business or political nature why
>    such proposals would be unrealistic.

Can you extend that sentence into a paragraph. It looks promising ;-)

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

Why is there a need to modify the generic solution (I mean changing
3775 for instance) if an alternative document is sufficient (like what
4285 does, for the reasons described in RFC 5419)

In the end, it's all about serving the Internet or specific
SDOs/vendors. I think the IETF in general and MIPv6 in particular try
and do the former.

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


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

IPsec cannot be used to protect all protocols. Hence the specification
of SEND for instance. But I think MIPv6 is among the few protocols which
have made effort to build their security on IPsec/IKE without relying
only on a simple sentence somewhere in the document stating "for
security needs, IPsec should be use". I would agree that more work is
needed on some aspects (interfaces) even if the WG is more interested by
pushing additional features.

If the security work on IPsec/IKE integration with MIPv6 had been
completed before the extension of the protocol (DSMIPv6, ...), this
may have prevented such issues.

I agree that some of the features described in companion documents of
MIPv6 have been described at a too high level and cannot be implemented
easily. 

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

Fully agree ;-)

>    Authors would also like to recognize Satyabrata Sahu, NK Garg,
>    Sandeep Minocha and Harsh Verma for working on the implementation.

What about discussing the specific technical details of the problems
they found during the implementation on the list and try and address
them one by one. Can I also ask what they implemented precisely and for
which specific platform? I would understand if that cannot be discussed
publicly, obviously.  

Cheers,

a+