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

[[e-mail] (Arnaud Ebalard)]

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.

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. And then it's easy to flag IPsec/IKE use as
overkill, all the more if you include RFC 5555 in the game.

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. 

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.

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

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

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.

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.

Cheers,

a+