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

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 23 Jul 2009 12:38:32 +0200

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+

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 23 Jul 2009 21:29:26 +1000

> IPv4, which let the NAT issue enter.

=> That's because the whole point of DSMIPv6 is to open the door for using
IPv4 use as a home address and a CoA (DS=Dual Stack). Teredo doesn't do
that, and it was never bound by the same security requirements of MIPv6. I'm
not advocating the points in the draft, I actually agree with your other
comments. But the problems with DSMIPv6/IKE interactions *are* due to NATs
and having two different NAT traversal mechanisms running in parallel
without a standard API between them.

 Due to that decision, the
> contributors of RFC 5555 on that topic.

=> I hope this helps.

Hesham

---

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 23 Jul 2009 13:46:18 +0200

Hi Hesham,

Hesham Soliman <[email-masked]> writes:

> IPv4 use as a home address and a CoA (DS=Dual Stack). Teredo doesn't
> do that,  and it was never bound by the same security requirements of
> MIPv6. I'm not advocating the points in the draft, I actually agree
> with your other comments. But the problems with DSMIPv6/IKE
> interactions *are* due to NATs and having two different NAT traversal
> mechanisms running in parallel without a standard API between them.

I agree.

>>  Due to that decision, the difficulties of IPv4/NAT have also impacted
>>  the use of DSMIPv6 with IPsec/IKE. 
>> 

Yes. Thanks.

Cheers,

a+

---

From: <[email-masked]>
Date: Fri, 24 Jul 2009 22:34:18 +0200

Hello,

>and specific to each of those about IPsec/IKE should be summarized in

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.

>possible way to go when you need to scale.

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

>difficulties of IPv4/NAT have also impacted the use of DSMIPv6 with

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.

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

>common MIPv6/IKE module (or at least complex interactions between

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.

>security subsystems to support MIPv6 needs but I'd like to be proven

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.

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

>I can't say about *BSD platform.

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

>But thanks for stressing that point.

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

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

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

>MIPv6 support: no business case and no standard interface to secure

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

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

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

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

>The difference is that MIPv6 tries and address that instead of leaving

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

>(what I consider) funny drawings like the following (RFC 5265):

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.

>link layer security for instance?

Yes. They do have security at the lower layers.

>Can a user of those networks move to

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

>is not the issue but the initial IKE negotiation and the number of SA

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.

>more.

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

> Moreover, it builds (even if some bits may be missing

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

>Can you list some (2 or 3) systems that are of common use today and that

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

>initial targets MIPv6 is trying to provide mobility for. Or am I missing

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.

>(BU/BA). In all cases, extending the IPsec stack to support MIPv6 is

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.

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

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

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

True.

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

A tall order IMO.

>>    MIP6 not being implemented widely.

YMMV (a disclaimer would have helped I guess)

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

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

I hope Domagoj can answer this.

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

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

>the context of MEXT but the WG is not supposed to work on that kind of

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

Agree.

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

>some section of 4877 and 5026, "extensive" is a bit too much.

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

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

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

>SDOs/vendors. I think the IETF in general and MIPv6 in particular try

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.

>MIPv6 have been described at a too high level and cannot be implemented

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

>which specific platform? I would understand if that cannot be discussed

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

---

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 27 Jul 2009 21:29:51 +0200

Hi,

> 3GPP2 and DSMIP6 has been specified by 3GPP in Rel 8. Will mention in

Thanks. 

> from implementations perspective.

Trying to provide a mobility solution that support all combinations of
IPv4/IPv6 CoA w/ IPv4/IPv6 HoA in environments which include NAT is the
main explanation. That been said, IPsec/IKE are not known to be very NAT
friendly. Said otherwise, NAT prevents IPsec/IKE deployment. It depends
on the way you see it. I think MIPv6 (and IPv6) designers made the
hypothesis IPsec and IKE were usable on IPv6 networks. It was kind of
decided to take a new start w/o NAT i.e. w/ the hypothesis of flat and
E2E-friendly networks. Accepting regressions in our security solutions
to keep coping w/ NAT is IMHO a bad path to follow.

> security module to work with (DS)MIP6 module and this is not a task

I think we agree. IMHO, supporting suspend (to RAM) for recent laptops
which includes a lot of features and devices is also not a task for the
faint-hearted. Nonetheless, people managed to implement it and make it
work. I think there are thinsg that are far more complex than the
required basic (I don't consider the dynamic address assignment
extension) interactions between the modules. My best arguments are:

 - spec is quite short.
 - implementation exist and work.

> proposed in I-D:  draft-korhonen-mext-mip6-altsec-01.txt

I read the draft. If I had to summarize the protocol the protocol I
would say the HAC provides the same function as a KDC in Kerberos
domains, granting HTTP tickets using TLS. Then, is looks 
like a kerberos-based relying on TLS (or even DTLS) for MIPv6 is IMHO a bad design idea. I
did not resist to take a *quick* look: 

 o there is an additional box in the picture, the HAC

 o "This specification defines a generic packet format, where everything
    is encapsulated inside an UDP."

 o You implement a mapping between TLS1.2 negotiated ciphersuite and ESP
   algs.

 o The only notable difference is that the SPI is prefixed with 4-bit
   PType field leaving 28-bit SPI value, although from the ESP
   processing point of view, the 4-bit PType and 28-bit SPI are handled
   as one "32-bit SPI".
 
 o section 5.2, the LS_RSA_WITH_AES_256_CBC_SHA is wrong, isn't it? It
   should map to AES-256 instead of AES-128.

 o The treatment of MN-CN route optimization is outside the scope of
   the document.

 o In 5.4.2, "The MN or the HA MAY switch between the encryption and
   plain text at any time based on local policies": what if an attacker
   knows the SPI and the sequence number. Can she start sending
   plaintext packets to one or another endpoint just by changing the
   ptype? 

 o You use the IPsec stack to protect traffic using ESP. You use SA for
   that purpose. There is nothing in the document about associated
   Security Policies (SP). Are the ones defined in 3776 reused?
   Can you clarify that point? 

At some point, considering you drop RO, I wonder why not going for one
of the following solutions instead of keeping MIPv6 in the picture: 

 - use of a DTLS-based VPN w/ session resumption
 - use of an IKEv2 MOBIKE-enabled VPN

> feasible option in all instances.

One of the problem you have with MIPv6 are the required interactions
with IPsec/IKE, for instance in order to update the SA endpoints. In
draft-korhonen-mext-mip6-altsec-01.txt, you skip this point and do not
explain how the interactions with the IPsec stack are done. Can you
clarify? 

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

Considering current work of Nokia developers in Linux Kernel, I expect
the future brother of the N810 which will run Maemo 5 to include a
post-2.6.28 kernel, which will make it almost directly MIPv6 w/
IPsec/IKE capable.

BTW, you may be interested by what is on http://natisbad.org/N810 + the
armel packages for Debian now available on the repository advertised on
http://natisbad.org/MIPv6. 

> it has not really progressed.

I could have kept incrementing the number at the end of the draft every
6 months or so but this is pointless if the chairs consider that the WG
should not work on such interfaces.

> seem to be easily surmountable.

I think we just disagree on that part ;-) I prefer the first option.

> sure I understand what you meant by "no standard interface to secure

[Probably] Due to their history, MS now consider the security aspects of
a protocol before putting it in their system. It's nice to have a
feature. It's a pain if it can be subverted with no way to prevent that.

> point is mobility may be a requirement in certain cases, whereas

I wonder if in two years Nokia (or other phone vendors) will have
non-smartphone phones. It's like looking today for a phone without a
camera.

> IPsec? So why is MIP6 having to rely on IPsec and IKEv2.

Because MIPv6 is not a L4 protocol but an extension of IPv6. 

> The design goals in the late 90s were based on some principles which
> are not very practical today.

You are thinking about "Client/Server" model forced by NAT I presume ? ;-)

> registration of an MN for MIP6 vs MIP4, you would see the difference.

Can you compare the amount of traffic exchanged between a MN and a HA
using IKEv2 to setup the SA with the traffic exchanged in an alternate
solution, say draft-korhonen-mext-mip6-altsec-01.txt?

> an existing and mature protocol like IPsec.

All the TCP and UDP based protocols my VPN carry without the need to
worry about the environment in which I am at a given moment.

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

Can you cite vendors and devices?

> becoming capable of connecting to the Internet but do not need an

Is that what you meant in the last sentence?

> interactions between the mobility module and the IPsec/IKEv2

I won't argue for DSMIPv6.

> aspects of the MN-HA communications.

At the moment, draft-korhonen-mext-mip6-altsec-01 relies on TLS, IPsec,
HTTP, BNF, RFC3948, ... and an additional box.

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

I am not the one you need to convince ;-)

> the case for a MIP6 capable IKE module.

Think RO. IMHO, if you consider MIPv6 and remove the RO, you may obtain
something that can easily replaced by a common VPN software w/ MOBIKE
support. 

> I hope Domagoj can answer this.

I'll wait for his answer.

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

The feature is available upstream now.

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

You can help me push things forward ;-)

> further implementations and hopefully gain some traction.

We do not need to change the whole protocol for that purpose. Mainly
specify the missing parts ...

> sidetracked into a discussion of why MIP6 is not implented in more

I am Looking forward to read it.

> implementation when you go through an exercise of doing so.

I won't. I just don't support DSMIPv6. Reread my email address more
carefully ;-) 

> DSMIP6 was done on a RHEL version of Linux.

let's do that part offline.

Cheers,

a+

---

From: jouni korhonen <[email-masked]>
Date: Mon, 27 Jul 2009 22:46:25 +0300

Hi Arnaud,

Commenting one point here at this time.

On Jul 27, 2009, at 10:29 PM, Arnaud Ebalard wrote:

[snip]

>   Can you clarify that point?

This is a common misunderstanding due to using term 'ESP' in the I-D.  
There is no reference nor intent to use IPsec as per RFC4301. The I-D  
only *reuses* the ESP format for encapsulation as what we came up  
ourselves looked more or less ESP format. We will (most probably)  
remove all references to 'ESP' in the future to avoid this mixup.

Cheers,
	Jouni

---

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 27 Jul 2009 22:33:03 +0200

Hi,

jouni korhonen <[email-masked]> writes:

> This is a common misunderstanding due to using term 'ESP' in the
> I-D. There is no reference nor intent to use IPsec as per RFC4301. The
> I-D  only *reuses* the ESP format for encapsulation as what we came up

Just to be sure: you mean you will not use the algorithms implemented in
the IPsec kernel stack but reimplement everything in userland?

Cheers,

a+

---

From: jouni korhonen <[email-masked]>
Date: Tue, 28 Jul 2009 00:26:06 +0300

Hi Arnaud,

Some more comments inline:

[snip]

> IMHO a bad design idea. I

Looks bad why? Please, list the points that lead to this conclusion. I  
would help us greatly.

[snip]

>   plaintext packets to one or another endpoint just by changing the

Anyone who gets on the link between the MN and the HA, could inject  
false packets if payload protection is not used. This would be true  
for plain MIP6 as well when IPsec is not used. If user payload  
protection (as per I-D) is used, then the change of PType will be  
noticed and those forged packets get dropped.

[snip]

> of the following solutions instead of keeping MIPv6 in the picture:

No one so far (from the MIP6 point of view) I have worked with has  
seriously requested it. Anyway, with the solution the I-D proposes, if  
the CN also implements the HAC functionality, the MN could bootstrap a  
security context with the CN and talk directly to the CN.

RO can be brought in, but I am not sure if it is worth the effort in  
this particular I-D.

[snip]

> explain how the interactions with the IPsec stack are done. Can you

There is no interaction with IPsec stack.

[snip]

> solution, say draft-korhonen-mext-mip6-altsec-01.txt?

You mean the IKEv2 generated traffic between MN and HA versus TLS- 
based generated traffic between the MN and the HAC? We could provide  
such.

[snip]

> HTTP, BNF, RFC3948, ... and an additional box.

TLS and HTTP. BNF processing is part of HTTP parsing anyway.

 From Section 5.4.
"Actually, when data protection is used, the construction of the  
packet on the wire is the same as an UDP encapsulated ESP packet in a  
tunnel mode as defined in [RFC3948]."

This does not mandate anything. It is an example. Will be removed to  
avoid the confusion.

[snap]

Cheers,
	Jouni

---

From: jouni korhonen <[email-masked]>
Date: Tue, 28 Jul 2009 00:32:27 +0300

Hi Arnaud,

> the IPsec kernel stack but reimplement everything in userland?

No IPsec kernel stack involved. I am not sure what algorithms you are  
referring here.

Cheers,
	Jouni

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 28 Jul 2009 10:02:08 +0200

Hi Jouni,

jouni korhonen <[email-masked]> writes:

> [snip] relying on TLS (or even DTLS) for MIPv6 is IMHO a bad design
> idea.
>

- Because TLS has been designed to secure transport streams ..
- ... not as a key exchange mechanism for L3
- Because you map TLS ciphersuites to some enc and hash algs to be
  used with IPsec.
- Because, pratically, you create yet another variation of what EAP-TLS
  does, but using HTTP and without reusing the guaranteed key material
  generated by TLS.

Again, can you argue why you don't directly use DTLS instead of some
TLS+ESP headers variations?

> for plain MIP6 as well when IPsec is not used.

Sure. But my concern is about the reverse scenario. Protection of data
is used. 

> If user payload protection (as per I-D) is used, then the change of
> PType will be noticed and those forged packets get dropped.

How? As pointed previously, there is nothing about the equivalent of
Security Policies discussed in the draft and you have that sentence:
"The MN or the HA MAY switch between the encryption and plain text at
any time based on local policies". IMHO, this is unclear to say the
least. 

> RO can be brought in, but I am not sure if it is worth the effort in

Maybe it is just me but without RO, mobility can be provided to clients
by a common VPN software.

> There is no interaction with IPsec stack.

So you reuse ESP format but have no interaction with the IPsec stack. Am
I correct on the following: you reimplement in userland all the ESP
related parsing which is available in the kernel stack.

Yes. Thanks. 

> This does not mandate anything. It is an example. Will be removed to

Ack. But I think you should clarify what (from the IPsec stack) needs to
be reimplemented in userland (ESP parsing, SADB?, SPD?, ...).

BTW, I think my question on how movement is handled (what needs to be
done on HA and MN) was worth asking. It was skipped in your reply.

Cheers,

a+

---

From: "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 28 Jul 2009 10:23:54 +0200

Arnaud, 

> - ... not as a key exchange mechanism for L3

Would there be any technical problem with this? With EAP-TLS that you
are mentioning below, TLS does the same thing for L2.  

Thanks,
Dirk

---

From: <[email-masked]>
Date: Tue, 28 Jul 2009 10:31:37 +0200

Hi Arnaud,

I will respond to your other comments as soon as I get some time..

But just one thing:

________________________________________
From: ext Arnaud Ebalard [[email-masked]]
Sent: Monday, July 27, 2009 2:29 PM
To: Patil Basavaraj (Nokia-D/Dallas)
Cc: [email-masked]
Subject: Re: Review of draft draft-patil-mext-mip6issueswithipsec-01

Raj> MIP6 by itself is useless today. Maybe 10 years from now when we hopefully have some deployment of IPv6 networks and is available natively on links, it would be an option.
The only practical solution at this time is DSMIP6 because it deals with the reality of the fact that MNs will be mostly attached via IPv4 and NATed networks.

Raj> Right... I noticed that already. I dont understand your reasons for not supporting DSMIP6.
Is it only because of the fact that DSMIP6 has to deal with NATs ;) ?
As I said for all practical purposes, implementing only MIP6 by itself is purely an academic exercise.

-Raj

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 28 Jul 2009 10:55:07 +0200

Hi,

"Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]> writes:

> Would there be any technical problem with this?

I should have written key provisioning. Anyway, I don't think there is
any *technical* problem with this apart from changing the initial
purpose of the protocol. The comment was meant to be generic,
i.e. against trying to do X at layer Y with a protocol that has been
done to do Z at layer W.

> With EAP-TLS that you are mentioning below, TLS does the same thing
> for L2.   

Yes, that's the reason I wonder why the draft doesn't use the same
scheme instead of creating a new one, i.e. it doesn't reuse the
*derived* key material instead of having the HAC push it over https.
There may be reasons but they are not discussed.

Cheers,

a+

---

From: "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 28 Jul 2009 11:13:03 +0200

Hi Arnaud,  

> -----Original Message-----
> From: Arnaud Ebalard [mailto:[email-masked]] 
> Sent: Tuesday, July 28, 2009 10:55 AM
> To: Kroeselberg, Dirk (NSN - DE/Munich)
> Cc: jouni korhonen; [email-masked]; [email-masked]
> Subject: Re: AW: [MEXT] Review of draft 
> draft-patil-mext-mip6issueswithipsec-01
> 
> Hi,
> 

I agree with the general comment. But it is always a problem to do such
thing. 

You can also see it as just establishing a TLS-secured tunnel and some
other http based 'key provisioning' scheme can be run through this
tunnel (I think this is the idea of the current draft). The advantage of
this is that other http-based exchanges than the default one can easily
be plugged in. TLS just secures the transport. Of course this requires
to look at stuff like man-in-the-middle attacks.
 
> There may be reasons but they are not discussed.

See above.

---

From: jouni korhonen <[email-masked]>
Date: Tue, 28 Jul 2009 12:16:14 +0300

Hi Arnaud,

Thanks for another round of questions & comments. See my answers inline.

> - Because TLS has been designed to secure transport streams ..

Ok.

> - ... not as a key exchange mechanism for L3

Do you have a better candidate if IKE is out of question?

> - Because you map TLS ciphersuites to some enc and hash algs to be

Hmm.. Didn't we agree already that there is no IPsec per se?

>  does, but using HTTP and without reusing the guaranteed key material

OK. I don't understand what do you mean by "without reusing the  
guaranteed key material generated by TLS"?

> TLS+ESP headers variations?

I don't have a good answer to this. Basically, we do not want to run  
the TLS handshake between the MN and the HA. That would have undesired  
implications during the handover.

> Sure. But my concern is about the reverse scenario. Protection of data

If protection of reverse tunneled traffic is used, then any  
modification of UDP encapsulated payload will be detected. Of course  
this requires that integrity check is done.

> any time based on local policies". IMHO, this is unclear to say the

You do integrity verification? The integrity check also covers the  
PType. That is "described" (cough) in section 5.5. I admit that the I- 
D need much more details and clarifications in the next revisions  
regarding these details, but going for +100 pages in the first  
revisions was not that appealing ;) Point taken though.

> by a common VPN software.

Well, that is true. However, MOBIKE has not been out that long yet (it  
is getting deployed now though). Again, the experience with  
interfacing with folks deploying mobility & VPN services is that they  
don't like the idea of protecting everything due for whatever reason.  
That usually kills the argument of using mobile VPNs for consumers.

> related parsing which is available in the kernel stack.

Parsing is no brainer tbh. But yes, you more or less replicate the  
encapsulation parsing.

> be reimplemented in userland (ESP parsing, SADB?, SPD?, ...).

Point taken. We'll add more clarification about this. Currently only  
the parsing of encapsulation is needed.

> done on HA and MN) was worth asking. It was skipped in your reply.

Hm. I seem to have missed it. I'll check that.

Cheers,
	Jouni

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 28 Jul 2009 11:17:41 +0200

Hi,

> I will respond to your other comments as soon as I get some time..

ok.

> Raj> MIP6 by itself is useless today. Maybe 10 years from now when we
> hopefully have some deployment of IPv6 networks and is available
> natively on links, it would be an option. 

Well, you should come to France ;-) At work, I have IPv6 (Nerim as a
provider). At Home, I have IPv6 (Free as a provider, which has more
than 5 millions clients who can activate IPv6 at home via a simple
clic (/64)).

> The only practical solution at this time is DSMIP6 because it deals
> with the reality of the fact that MNs will be mostly attached via IPv4
> and NATed networks.

In order to be more useful than MIPv6 (using Teredo when in IPv4
networks) or a direct use of the available private IPv4 address in a
common network, I think one needs a public IPv4 address as HoA. IMHO,
this is a non starter in term of deployment.

For me, MIPv6 provides address stability and e2e.

> for not supporting DSMIP6.

 - Complexity
 - No availability of the protocol as an open source implementation
 - No public IPv4 address to use for a deployment (or expensive)
 - MIPv6 + Teredo works fine with me

> is purely an academic exercise.

It may depend where you live. 

a+