Re: [MEXT] Rethink on Mobile IPv6

[Hesham Soliman <[e-mail]>]

On 5/03/10 8:58 AM, "[e-mail]" <[e-mail]>
wrote:

> 
> Hi Hesham,
> 
> 
> On 3/3/10 8:25 PM, "ext Hesham Soliman" <[e-mail]> wrote:
> 
>> Hi Raj,
>> 
>> A couple of thoughts.
>> First, you've redefined the purpose of MIPv6 to be about setting up a tunnel
>> between the MN and the HA. Whether this is correct or not, it's worth noting
>> that your basis for such definition is unknown. It certainly doesn't match
>> our reference for MIPv6 (RFC 3775).
> 
> As I wrote, the very basic functionality of MIP6 is to establish the tunnel
> and then manage the end-point change. This is my PoV. But maybe you see it
> differently. 

=> I know, I wanted to point out that this is one PoV and not an agreed upon
definition. There are people on the list who might not know that.

> 
>> 
>> Regarding the complexity of DSMIPv6. Arnaud is 100% right in his response
>> and this was discussed on the mext list more times than I can remember. The
>> complexity is due to NAT traversal. Yes, we could have reduced the
>> complexity if we relied on MIP-only traversal techniques instead of having
>> both MIP and IPsec traversal run simultaneously, but what is the other
>> alternative for negotiating a security association behind a NAT?
> 
> I am not disagreeing that part of the complexity results from the presence
> of a NAT and having to develop means to traverse the NAT.
> I am of the view that the use of IPsec and IKEv,v2 in conjunction with
> Mobile IPv6 is complex. There is really no good reason to bind MIP6 with
> Ipsec and IKE. This is a legacy decision and one that is just proving to be
> plain wrong. An IPsec SA between the MN and HA is not required for enabling
> IP mobility. We overcome the NAT related complexities by dropping the
> reliance on Ipsec/IKE. The security model for MIP6 is a relic that needs to
> be revisited for simplification of the protocol itself.

=> Removing IKEv2 will not remove the NAT issues and depending on what you
will replace it with, it might make it worse. The problem here is not in the
name of the technology, it's what it does. I'm very open to listening to new
ideas on how to simplify things, but what I don't accept is to define the
goal to "remove IPsec and IKEv2". That's not a goal. IKE provides a way of
negotiating an SA, IPsec applies those credentials to securing packets. Now,
these are the two basic functions required to secure a connection. Do you
want to replace them because they're badly designed? Or because you believe
we don't need one of those functions? I'm sure it's the former not the
latter. So it's the former, let's see something that it better designed and
see how it works under the same conditions.
The whole idea of interoperability being an issue is a non-starter for me
because it's not technology-specific, so solving it by designing a new
protocol seems ...counter-productive.

> 
>> The problem *is* NAT. I'm afraid that once you plant the seeds of hackiness
>> (if that's a word) by using NATs you have to harvest the output at some
>> point. There is no free lunch when you have a deployed base of 2 billion
>> users.
> 
> Deployed base of 2 billion users??? You mean behind a NAT? But none of them
> will ever use MIP6/DSMIP6 (IMO at least) if we have to employ the hackiness
> of traversing NATs. Obviously NATs are not going away for sure and we will
> probably have other variants as well in the future (NAT64s and NAT464s
> etc.). We do not have as much of an issue with the NATs if we don't have to
> rely on Ipsec/IKE,v2.

=> I wish it was so easy. You're assuming that if we remove IKE/IPsec NAT
will not be causing problems? I think there are problems with NATs
regardless. These are not technology specific problems, they're fundamental
problems because of how a NAT works.

> 
>> 
>> I continued to suggest (for about 6 years now) that we use CGAs for MIPv6.
>> It's by far the cleanest solution we have. My best description to the
>> resistance of adopting CGAs is: Politics. There is no technical reason for
>> not using them and we all know that. So if you want to come up with
>> alternatives, you'd be doing the community a disservice if you don't
>> seriously consider CGAs.
> 
> I think we should consider all alternatives. I don't know if you have
> proposed how CGAs could be used in the context of MIP6 security. I am more
> than happy to build a MIP6 protocol that uses CGAs if such an approach would
> reduce the complexity.

=> Great. I still don't know if it will be an improvement over IKEv2 in
terms of this discussion, but I'm glad you're open to all approaches. Of
course, whatever we do, there will always be the challenge of setting a
default mechanism, and potentially negotiating the security mechanism.

>> We've already seen what happens when we produce half cooked
>> security proposals tailored to a specific SDO's needs (read: RFC 4285).
> 
> 4285 IMO is quite okay in certain deployments. If the network in which you
> deploy MIP6 already has a means to securely exchange keys (eg. 3GPP/2, WiMAX
> networks) then you could very well use RFC4285. Why would you need to
> establish an IPsec SA using IKE/v2 between the MN and HA in such networks?

=> I think this shows that we still need to get to the bottom of what you
think is wrong with IPsec. 4285 replaces the IPsec authentication with a
"different" header. That's all it does. IMO that's completely useless and
the only reason I could see people doing that is some kind of ideology or
allergy against the word IPsec. 4285 is exactly the same as using IPsec AH
with pre-shared keys. Except, it's designed in a terrible way whose flaws
were discussed on the mailing list for a long time.
I don't think we need to design a new Authentication header, we already have
one that can be used without IKE.

Hesham

> Just does not make sense. And FWIW, I am not raising the topic of
> simplifying MIP6/DSMIP6 with a specific solution in mind. But rather from
> the perspective that we need to revisit the protocol and simplify it to meet
> the basic mobility needs first.
> 
>> 
>> I look forward to the continuation of these discussions.
> 
> Sure. 
> 
> -Raj
>> 
>> Hesham
>> 
>> 
>> On 4/03/10 2:55 AM, "[e-mail]" <[e-mail]>
>> wrote:
>> 
>>> 
>>> Mobile IPv6 (RFC3775) has been an RFC since 2004, and Dual-stack
>>> Mobile IPv6 (RFC5555) since 2009. Implementations of the protocol has
>>> been lacklustre to say the least. Several SDOs have considered MIP6
>>> and DSMIP6 as a solution for interworking and mobility between
>>> different access technologies and only 3GPP has adopted it in a very
>>> limited manner for Rel 8 (for use on the S2c interface) with the
>>> likelihood of it being actually deployed quite low (IMO).
>>> 
>>> While there are many reasons that can be attributed to the lack of
>>> implementations and use, one that I would like to raise is the the
>>> concern with the overly complex security model that MIP6/DSMIP6 relies
>>> on today. MIP6/DSMIP6 requires IPsec and IKE/IKEv2 (RFC3776/4877) to
>>> secure the signaling between the MN and HA. The fundamental purpose of
>>> MIP6/DSMIP6 is to provide mobility to hosts. At a very high level the
>>> MIP6/DSMIP6 protocol boils down to the ability to setup a tunnel
>>> between the MN and HA and update the MN tunnel end-point whenever
>>> there is a change in the associated IP address (CoA). The signaling to
>>> establish the tunnel needs to be secure. But using a protocol like
>>> IKEv2 and IPsec to achieve this security is just an overkill. It
>>> increases the complexity of the implementation as a result of many
>>> factors that have been captured in I-D:
>>> draft-patil-mext-mip6issueswithipsec and discussed in the MEXT WG
>>> meetings.
>>> 
>>> Given the objective of the protocol is to enable IP mobility for hosts,
>>> it should focus on doing that well in a manner that makes it easy to
>>> implement/adopt/deploy/scale. My opinion as a result of implementation
>>> experience is that MIP6/DSMIP6 can be significantly simplified,
>>> especially the security architecture. The protocol as specified
>>> currently in RFC3775/RFC5555 is a kitchensink of features. Getting back
>>> to basics of simply establishing a tunnel between the MN and HA and
>>> managing that tunnel is all that is needed and would potentially see
>>> the light of day in the real world.
>>> 
>>> You may want to call it as Mobile IPv6-lite if you wish. But I do
>>> believe that a simplification of the protocol is needed without which
>>> I fear it will remain an academic exercise with many years spent in
>>> developing a spec. I hope the working group and people who are
>>> involved in mobility related work would consider undertaking such an
>>> effort in the IETF.
>>> 
>>> -Basavaraj
>>> 
>>> _______________________________________________
>>> MEXT mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mext
>> 
>> 
>