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

[<[e-mail]>]

Hello,

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

MIP6 itself has been specified as a solution by NWG in WiMAX forum,
3GPP2 and DSMIP6 has been specified by 3GPP in Rel 8. Will mention in
the next rev of the I-D.

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

Right. You could configure the SAs manually. But that is not really an
option.

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

Agree. But the point is because of the security architecture of MIP6
is based on IPsec, the issues with IPv4/NAT are inherited by DSMIP6
and as a result the protocol becomes much more complex... At least
from implementations perspective.

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

My opinion is that DSMIP6 [RFC5555] did not really want to change the
fundamentals of MIP6 and hence did not really tackle the security
architecture issue.

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

Agree. And the issue is with the fact that complex interactions are
needed between the modules. Basically you cannot expect to use the
existing IPsec/IKEv2 engine on a host to work with your MIP6
implementation with no changes. You end up having to modify the
security module to work with (DS)MIP6 module and this is not a task
for the faint-hearted.

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

Take a look at the TLS based security architecture framework solution
proposed in I-D:  draft-korhonen-mext-mip6-altsec-01.txt
We believe that it does not require changes to the security engine on
the host. It is a solution which uses the APIs and libraries of TLS on
the host without having to modify them.
The problem with IPsec/IKEv2 and MIP6 is that we end up having to
modify the security subsystem to make it work and this is not a
feasible option in all instances.

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

Right... And this is what we have worked with on our implementation as
well. While we can use these interfaces, I should say that it is still
not easy and again these are not available on all platforms.

> - patches exist for racoon2
>
>I can't say about *BSD platform.

Or for that matter Symbian or Maemo (linux) etc..

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

Right.. We did note work (reference) done by you in this context. But
it has not really progressed.

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

Yes... The last option is what we are recommending. The others do not
seem to be easily surmountable.

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

Having worked on this implementation, I am not arguing that it cannot
be done. All I am saying is that it is a real pain to implement it and
get it working. Additionally while it is possible to do this on open
source where you have control of all the modules, it is not
necessarily the case on all platforms. For example you would not be
able to modify the IPsec/IKEv2 modules on Symbian if you were building
the MIP6 module. Only Symbian could do that. And the same goes for
many other platforms as well.

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

No business case from the perspective of MS... Maybe. But I am not
sure I understand what you meant by "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.

Support for IPsec/IKEv2 can be built. But most vendors would shy away
from it. To make this protocol even have half-a-chance of being
implemented by vendors the security architecture needs to be a lot
more simpler than the current one.

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

Again, note a proposed solution in the I-D mentioned above which is
based on TLS (reuse of another existing security building block).

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

Let me give you an example.. A mobile phone (not the smartphone types
lets say) does not need IPsec/IKEv2. However it does not need mobility
support on networks which would provide mobility via an HA. So the
point is mobility may be a requirement in certain cases, whereas
IPsec/IKEv2 is not.

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

But I would find it very hard to see it actually being used.

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

IPsec in hosts is used primarily (and probably only) by VPN
applications. Is there any other protocol on a host which requires
IPsec? So why is MIP6 having to rely on IPsec and IKEv2. The design
goals in the late 90s were based on some principles which are not very
practical today.

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

Yes. They do have security at the lower layers.

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

They could. Depends on the type of data and how concerned they are
about protecting it (i.e level of paranoia).

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

The number of messages exchanged to setup the IPsec SA is an
issue. Especially when you compare it with the registration process
required for MIP4. So if you compare the number of steps for
registration of an MN for MIP6 vs MIP4, you would see the difference.

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

More is not necessarily good :) (Kitchen sink protocol design)

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

Well show me another protocol on the host which relies on the reuse of
an existing and mature protocol like IPsec.

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

Proprietary OS' come to mind. Devices with these types of OS' are
fairly common.

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

Well.. Nokia devices based on Maemo and Symbian do include IPsec
support. But for lower end devices which are primarily intended for
voice service and some data, there is no IPsec even though there is an
IP stack. Additionally I dont know about many other devices which are
becoming capable of connecting to the Internet but do not need an
IPsec stack.

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

I think this where I would disagree. At least from our experience of
doing a DSMIP6 implementation, the challenges are primarily in the
interactions between the mobility module and the IPsec/IKEv2
modules. YMMV.

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

Making changes to the IPsec or IKEv2 modules may not always be an
option. Especially if you have no control of those modules on a
host. You would then have to rely on these interfaces being
standardized and implemented on all hosts for the mobility module to
rely on.

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

I think we can do simpler security solution than IPsec/IKEv2 which
would simplify the implementation vastly while preserving the security
aspects of the MN-HA communications.

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

True.

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

A tall order IMO.

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

YMMV (a disclaimer would have helped I guess)

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

A merged MIP6/IKE module is not a feasible option. Given that IKE is
used as a means to setup an IPsec SA for VPN purposes only, I dont see
the case for a MIP6 capable IKE module.

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

I hope Domagoj can answer this.

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

Right.. Our implementation experience has been with Strongswan as well.

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

Bummer.. And hence essentially no real solution being available.

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

Agree.

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

Guess we agree on some aspects...
But I concur about the fact that DSMIP6 istelf does not really make
the security architecture any more complex than it is as specified by
MIP6. It suffers from the security paradigm adopted by MIP6.

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

Okay.. But you know "Objects in mirror..."

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

I think vendors will shy away from (DS)MIP6 implementation after they
see the complexity or have made some attempts to experiment with
it. Making the protocol easier to implement at least would spur
further implementations and hopefully gain some traction.

>
>>  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 ;-)

Will try in the next rev... But I dont know if we want to be
sidetracked into a discussion of why MIP6 is not implented in more
platforms today.

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

And the IETF could do a better job and make the life of vendors easier
by providing solutions which are pragmatic and not based on some
design philosophies which are outdated.

There is IMO no shame in admitting that IPsec/IKEv2 is not the best
security framework for MIP6. Either the IETF does something to address
the concerns raised by vendors and implementers to develop something
that can simplify the protocol or let it sit on the shelves and die.

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

Thank you. I think you will realize the complexities of the
implementation when you go through an exercise of doing so.

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

We can discuss this offline. But I can say that the implementation of
DSMIP6 was done on a RHEL version of Linux.

Thanks for your comments.

-Raj

>
>Cheers,
>
>a+