Subject: [MEXT] FW: New Version Notification for draft-patil-mext-mip6issueswithipsec-00

From: Basavaraj Patil <[email-masked]>
Date: Mon, 27 Oct 2008 12:27:33 -0500

FYI,

------ Forwarded Message
From: ext IETF I-D Submission Tool <[email-masked]>
Date: Mon, 27 Oct 2008 09:55:13 -0700 (PDT)
To: Basavaraj Patil <[email-masked]>
Cc: Charles Perkins <[email-masked]>, <[email-masked]>
Subject: New Version Notification for
draft-patil-mext-mip6issueswithipsec-00

A new version of I-D, draft-patil-mext-mip6issueswithipsec-00.txt has been
successfuly submitted by Basavaraj Patil and posted to the IETF repository.

Filename:  draft-patil-mext-mip6issueswithipsec
Revision:  00
Title:   Issues related to the design choice of IPsec for Mobile IPv6
security
Creation_date:  2008-10-27
WG ID:   Independent Submission
Number_of_pages: 15

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

The IETF Secretariat.

------ End of Forwarded Message

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 27 Oct 2008 22:40:03 +0100

Hi,

Comments inline below. I am certainly biased on the topic but I try to
keep my comments below objective. Don't take the ones with smileys too
seriously.

> Abstract
>    revisiting this decision

At least, this will not fit in the scope of 3775bis ;-)

>    in view of the experience gained from implementation

That is fair!

>  and adoption in other standards bodies.

Is that fair?

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

                                                                   ^^^
                                                                 another

>    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
>    discussions between the years 2000 and 2004.  Implementation
>    experience with Mobile IPv6 and the security variants with which it
>    has been specified in some SDOs indicates a need to revisit the
>    design choice for MIP6 signaling security.
> 
>    This document discusses the issues and concerns with the use of IPsec
>    for MIP6 security and proposes revisiting the security design for
>    MIP6 protocol.
> 
> 3.  Terminology
> 
>    This document refers to [RFC3775][RFC4877] for terminology.
>
> 4.  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 was also intended to be a default component of the IPv6 stack
>    and was the preferred protocol choice for use by any other IPv6
>    protocols that needed security.  Rather than design security into
>    every protocol feature the intent was to reuse a well-defined
>    security protocol to meet security needs.  Hence Mobile IPv6 has been
>    designed with a direct dependency 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.  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

     ^^^^^^^^^
     IMHO, it is not complete.

>    Revised IPsec Architecture [RFC4877] in April 2007.  This [RFC4877]
>    is considered as the default security protocol solution for MIP6 and
>    updates [RFC3776].
> 
> 5.  Problem Statement
> 
>    Mobile IPv6 is encumbered by its reliance on IPsec 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 [DSMIP6].

The problem of IPsec and DSMIPv6 is NAT, which is an IPv4 issue.

>    IPsec SAs between the MN and HA are established either manually or by
>    the use of IKEv2.  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.

>    The problem in summary for MIP6 is the dependence on IPsec and IKEv2
>    for operation.

You see it as a problem instead of seeing it as a *global* *solution* for
IPv6 security. IPsec is usable and used on IPv6 networks.

> 6.  Issues with the use of IPsec
> 
>    This section captures several issues with the use of IPsec by MIP6.
> 
>    (1)  The design of Mobile IPv6 emphasized on 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.

As you say, it is true in many host implementation today; including many
mobile devices. It seems you want to remove IPsec/IKEv2 from IPv6
devices, use a different solution for protecting MIPv6 signaling. Let's
say you have managed to do that: any solution for data protection? any
solution for protecting common IPv6 traffic to/from those nodes?
Specific solutions too?

>         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.  The security associated with MIP4
>         signaling is integrated into the protocol itself.  MIP4 has been
>         successfully deployed on large scale in several networks.

No sarcasm at all: large scale public or *private* network? Can you give
examples?

Another note: I don't know any administrator that can give the udp port
number for MIP4. They all know IPsec and may even be able to give
protocol numbers for AH and ESP.

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

That's not true. See draft-ebalard-mext-pfkey-enhanced-migrate-00. This
is the only need from an interface perspective between IPsec/IKE and
MIPv6. There are public implementations available:

- Linux 2.6.28 will be fully compliant with the feature
- Patches for racoon have recently been posted. They are currently being
  reviewed.
- patches for Linux MIPv6 implementation maintained by USAGI people are
  available. 

The only problem is the lack of traction in mext and the lack of
coordination with IPsec WG.

>         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 changing to IPsec policies or other.

I do not fully understand the argument.

>    (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 of mobile
>         nodes which could number 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.

IPsec is efficient. What would you propose as an equivalent solution
(security wise) that would be more scalable than IPsec?

>    (4)  The implementation complexity of Mobile IPv6 is greatly
>         increased because of the interaction with IPsec and IKEv2.

This is just false. Please, just take a look at previous draft. Look at
the additional amount of code added in Linux kernel to support the
feature, for instance.

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

Are you trying to remove IPsec/IKE of the picture with the hope that
DSMIPv6 issues will also disappear?

>    (5)  IPsec and IKEv2 is not implemented in every IPv6 or dual stack
>         host.

Not in all, but most stacks.

>         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.  MIP6 without any dependencies
>         on protocols for security is easier to implement and has wider
>         applicability.

The idea of having every specific protocol specify its own security
mechanism is just the worst idea ever: interoperability issues, more
flaws, more code, ...

>    (6)  [RFC4877] which specifies the use of IKEv2 and IPsec with Mobile
>         IPv6 essentially results in a variant of IPsec which is specific
>         to Mobile IP.  Hence this results in added complexity to
>         implementations.

???

>    (7)  Mobile IPv6 needs to be capable of being deployed in situations
>         where alternative security mechanisms are already well-
>         understood by the network administration.  It should be possible
>         to enable Mobile IPv6 to work in situations where alternative
>         security mechanisms already supply the necessary authentication
>         and privacy.

Can you be more specific and give some example?
 
>    (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.

That issue was solved. I don't see the point.

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

True.

>    (10) In certain environments the use of IPsec and IKEv2 for
>         establishing the SA is considered as an overhead.  Bandwidth
>         constrained links such as cellular networks and air interfaces
>         which are in the licensed spectrum tend to be optimized for user
>         traffic.  MIP6 signaling with the IPsec overhead and the IKEv2
>         messages are viewed negatively.  It is more acceptable to have
>         signaling without IPsec encapsulation.

I must be missing something. Are you removing the security or are you
considering another mechanism when doing such a comparsion? The former
does not make sense, in the case of the latter, which one?

>    The issues listed above have been a cause for MIP6 not being
>    implemented widely or adopted by other SDOs which are considering IP
>    mobility solutions.

Which ones? What did they choose? What provides security for the mobile
solution's traffic? What provides data security?

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

True. RO would look better with IPsec ;-)

>    The design or the security architecture for MIP6 needs to be
>    revisited and a solution that does not rely on other components
>    developed.

MIPv6v2 ? ;-) At least, with the generic notification, this will be
easier to distinguish.

> 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 security architecture needs to be revisited.
> 
>    The experience gained over the last few years indicates that IPsec
>    cannot necessarily be used as a generic solution for security.  The
>    design choice made for MIP6 in the initial stages no longer are valid
>    and is hampering the implementation and use.

What is hampering the implementation and use is the lack of IPv6
deployment and the decision of the WG not to complete IPsec/IKE
integration and spend time on additional *features*. At the end,
security work is not complete and you have many features that are now in
the way.

This is not an argument but it is worth mentioning: at some point,
MS had a (experimental) MIPv6 implementation on their OS. This has been
removed from latest versions of the OS while the IPv6 stack was
promoted. From a discussion with a developer of the stack, *one* of the
reason was that security work was not over.

Cheers,

a+

---

From: Frank Xia <[email-masked]>
Date: Fri, 31 Oct 2008 11:45:32 -0500

Hi Raj

It is a very interesting draft.

Issue #1 "... As a result of this dependence,
 MIP6 is no longer a standalone host-based
 mobility protocol..."

General speaking, I am with you. The protocol
is not elastic enough.  IPSec is  a very good
tool which MIPv6 should make use of .
On the other hand,  it is better to keep the
protocol minimal self-sufficient  in case
some external dependencies can not be satisfied.

Issue #2 "...Use of IPsec with Mobile IPv6 requires
configuration which in many cases is  not easily done
because of reasons such as enterprise environments
preventing changing to IPsec policies or other"

Question:  could you give me one case as an example?

Issue #3 "...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"

I can partly agree with you because it is optional
to use IPSec for data traffice between MNs and HAs.

Issue #5 " MIP6 without any dependencies
on protocols for security is easier to implement and
has wider  applicability'

I agree to decouple MIPv6 from IKE/IPSec.

BR
Frank