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

Hi Basavaraj,

Basavaraj Patil <basavaraj.patil@nokia.com> writes:

>>>    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.
>
> NAT is an issue. But the combination of IPsec and NAT is not helping either.

I still think the issues associated with the path selected for DSMIPv6
are used as an argument against IPsec for MIPv6. If you consider MIPv6
and the networks it is expected to operate in (IPv6 ones), there is no
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.
>
> Ipsec is no doubt used widely. But it is just not the right solution for
> securing MIP6 signaling. Ipsec in fact is used primarily in IPv4 networks
> today. However there is no reason for relying on Ipsec for MIP6 security. It
> is equivalent to Ipsec being the hammer for every security nail.

When "Security Considerations" sections of IETF protocol specification
simply states "IPsec can be used to secure the protocol", I agree. But
in MIPv6 case, time has been spent and specifications have been written
to provide a working solution.

>>> 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?
>
> MIP6 is not a protocol that is intended to solve the data protection
> problem.

If you are an operator and your Mobile Nodes are only moving in a closed
environment, probably. When you are a common user on real *foreign*
networks, I bet that you expect some ability to protect your data, at
least between you and you HA.

> If you need data protection use something else.

IPsec/IKE seems like the right solution to me. It is the one I use.

> And what other common IPv6 traffic between the MN and HA needs protection?
>
> MIP6 is a protocol for enabling host mobility. The signaling messages need
> to be secured. So lets just solve that.

IMHO, it has been solved already. Someone tries to reopen the case
because of DSMIPv6 issues with current solutions or other specific
incompatibilities with some internal practices, AFAICT. Please, note
that I am not against alternative solution if they are chosen for the
right reasons and if their drawbacks and scope of deployments are
known.

If the intent is to provide a specific operator compatible solution
with no expected ability to support movement to common foreign networks
or expected support for movement to IPv4 network, that goal should be
clearly stated. In a sense, I prefer how things are stated in
draft-ietf-mip6-whyauthdataoption-07.txt.

>>>         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?
>
> Large scale public networks. Almost all CDMA networks today use Mobile IPv4.
> I believe CDMA mobiles number in the 100s of millions.

ok. thanks.

>> 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.
>
> I guess you have been talking to the wrong people. I agree that MIP4 use in
> the enterprise does not exist and hence I would'nt expect an admin in such a
> domain to know the MIP4 UDP port number. But of course literally every
> enterprise has a VPN gateway. So it is not surprising that they would know
> Ipsec and not MIP4.

ok. 

>>>    (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.
>
> The lack of traction is because of the complexity of integrating MIP6 with
> Ipsec and IKEv2.

I don't think this is the *real* issue: the changes required at the
IPsec stack level and in the IKE implementations to support MIPv6 are
not so huge.

>  And given this complexity and other reasons the lack of
> traction is understandable. You may be an exception here and not the
> norm.

yes. I don't work for a phone manufacturer or a network operator.

>>>         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.
>
> What I meant was that enterprise hosts which have Ipsec (VPN) clients
> essentially specify rules which tunnel all traffic via their gateway.
> Modifying these policies to allow only MIP6 signaling to be transported over
> Ipsec is not easily done because administrators do not allow an end user to
> change those policies.

Well, I would not expect users to do those changes either but in the
end, why would they need to switch off the protection of data to only
have MIPv6 signaling transport-mode protected. From my point of view,
as expected by the reference document, MIPv6 signaling is protected
using transport mode and data traffic is protected using tunnel
mode. This just perfectly fit the need, doesn't it?

>>>    (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?
>
> Let me just say that there are alternative means of securing MIP6 signaling
> and the intent is to get the WG to begin work on developing such a solution.

Would you agree with the following summary: the intent is to provide a
specific solution targeting *only* protection of MIPv6 signaling. Unlike
currently specified IPsec/IKE protection, extending it to support
protection of data traffic (MN-HA and possibly MN-CN) at some point is
not expected and will not be easily possible. This solution would be in
sync with the specific networks it is expected to be deployed in.

>>>    (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.
>
> I guess all I can say is YMMV. And it is not about the amount of code.

Is that for "Your Mileage May Vary" or "Your Market May Vary" ? :-)

>>>         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?
>> 
>
> Yes... The issues with Ipsec/IKE are applicable to MIP6 and DSMPI6.

I don't think there are issues with MIPv6. I expect there are with DSMIPv6.

>>>    (5)  IPsec and IKEv2 is not implemented in every IPv6 or dual stack
>>>         host.
>> 
>> Not in all, but most stacks.
>
> The assumption at the time of MIP6 design was that every IPv6 stack would by
> default include Ipsec. This is not true.

?

>>>         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, ...
>> 
>
> I am not suggesting that every protocol specify its own security mechanism.
> Lets look at what works and simplification.

Hum. You don't suggest that but you want that for MIPv6. If everyone
does that for his protocol (HIP, ...), we just have what I describe
above.

>>>    (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?
>
> As an example consider a cellular network where access authentication
> between the MN and the home AAA is based on credentials and keys. The same
> can be leveraged for securing the MIP6 signaling.

Tell me if this is correct:

- cellular network operator have AAA deployed
- they have IPv4
- they have specific architectures they are used to manage
- they don't have IPsec/IKE deployed (for end devices)
- they don't need to secure data traffic

>>>    (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?
>
> There is no need for securing the traffic.

Let say operators do not have the need.

> If data security is needed, use something else (as I stated
> above). MIP6 is not a solution for securing the traffic. 

No, it is not.

>>> 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 ;-)
>
> RO is a feature that is even less understood and used. Just get mobility
> deployed first and RO can come subsequently.

cellular network operators will not allow that anyway, will they?

>>>    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.
>
> MIPv6 simplified is what I would call it.

ok.

>>> 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.
>
> The WG can specify more Ipsec/IKE documents. But that will in no way ease
> implementation of the protocol and adoption. Simplifying the protocol and
> solving the mobility problems based on what we know now and not relying on
> the assumptions made at the time of MIP6 design originally will help.

Sorry, I don't see it that way.

I write stuff, have it reviewed, implement it, correct it based on that
feedback. And at the moment, I don't see issues with IPsec/IKE being
used for MIPv6 protection (and yes, for both signaling and data
traffic).

The only issue I see is operators that don't see how this IPsec/IKE
protection could fit in their networks (management, billing, IPv4
compatibility, ...). AFAICT, some documents have already being produced
towards that goal. If this is the issue, it should be stated that way.

Is that correct?

>> 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.
>
> Or maybe they found the complexity of integrating the security module
> (Ipsec/IKEv2) with the MIP6 module simply too great and not worth the
> effort??? :)

Thanks for you answers Basavaraj.

Cheers,

a+

_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext