Re: [Int-area] [MEXT] Rethink on Mobile IPv6

[<[e-mail]>]

Inline:


On 3/3/10 11:25 AM, "ext Arnaud Ebalard" <[e-mail]> wrote:

> Hi,
> 
> with some salt ...
> 
> <[e-mail]> writes:
> 
>> 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.
> 
> I don't think RFC 3775 is. There are some questionable features (DHAAD,
> ...) but it's a good document IMHO. As for RFC 5555, it inherits the
> complexity of NAT traversal mechanisms. Blame NAT, not IPsec/IKE for
> that.

RFC3775 is indeed a good document given the amount of time and effort
invested in it (6+ years). While NAT does indeed add further complexity in
the case of RFC5555, the dependency of MIP6 on IPsec/IKEv2 is also
unwarranted. 

> 
> Sure, it is always possible to reduce MIPv6 to a simple data tunnel
> between a MN and a HA which needs to be updated from time to time via
> some secure signaling.

At least there is a far better likelihood that it would at least get
implemented and used with a simpler approach.

> And then it's easy to flag IPsec/IKE use as
> overkill, all the more if you include RFC 5555 in the game.

I am going to stick by my view that Ipsec/IKE is an overkill for the purpose
of IP mobility. 

> 
> But MIPv6 is expected to provide more than that.
> 
> First, the Route Optimization is an integral part of the protocol and
> IMHO, without it, MIPv6 can advantageously be replaced by some
> MOBIKE-enabled IPsec VPN solution or some DTLS-based equivalent.

RO AFAICT is not even a consideration for many deployments. The industry
will decide if Mobike or MIP6 or something else will meet the requirements.
Building all kinds of fancy features simply to bolster the case for MIP6 is
not going to help. In fact it will do the exact opposite.
And RO can be specified as a plugin (if you will) for those deployments that
care about it. But it does not have to be a fundamental part of the basic
protocol. 

> 
> Additionally, MIPv6 is probably just a milestone and the main building
> block for NEMO in many scenarios: in those scenarios, the ability to
> secure the data tunnel with the HA to protect traffic from MR's clients
> sometimes make a lot of sense. Future aeronautical networks will have
> that need, in order to provide protection of data traffic, no matter
> the wireless communication link or the foreign network. IPsec/IKE is
> perfect for the job.
> 

The use of IPsec/IKE comes at a cost. Lets see what the requirements for
these aeronautical networks are and whether they can be met via
non-IPsec/IKE security. Imagining all kinds of requirements that may exist
in the future will result in building a protocol that does not meet the
basic needs. You could just as well build a protocol that is simple to begin
with and then add the extensions for those deployments which have specific
needs. 

>> 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.
> 
> Why don't you write a draft for that MIPv6-lite protocol? It seems like
> the best approach to see if people are interested.

Yes. Something to do.
 
> Personally, I will continue to work on finishing the integration of
> IPsec/IKE and MIPv6 (for the RO part).

We did this for DSMIP6 (without RO). And understand the complexity involved.
 
> At some point if you write the draft, get implementations done, get
> people to use your protocol, if they ask for some security for tunneled
> data (let say for nemo) and secure RO (say for releasing the core of
> their architecture), I suggest pointing them to MIPv6.

They should be able to tell from such a spec about RFC3775 and the extensive
feature set and capabilities.

> 
> As a side note, I have MIPv6 and IPsec/IKE running on my Nokia N900
> (Native IPv6 on 3G and Wifi) and the main problem I have with that
> setup are not IPsec/IKE related: they are due to Cisco firewall in the
> network which basically drop packets with RH2. If you write your
> MIPv6-lite draft, I would suggest getting rid of HAO in Destopt and
> RH2.

Thanks for the suggestion.
We will have DSMIP6 (with security based on draft-korhonen-mext-mip6-altsec)
on the N900 sometime in the next few months. And possibly even an HA that is
accessible hosted by us for interop and testing.

-Raj

> 
> Cheers,
> 
> a+