Re: [Int-area] Rethink on Mobile IPv6

Sri Gundavelli <sgundave@cisco.com> Thu, 04 March 2010 06:58 UTC

Return-Path: <sgundave@cisco.com>
X-Original-To: int-area@core3.amsl.com
Delivered-To: int-area@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A762128C385; Wed, 3 Mar 2010 22:58:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.051
X-Spam-Level:
X-Spam-Status: No, score=-10.051 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaEK9vZwtZlb; Wed, 3 Mar 2010 22:58:11 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 42EAC28C2C5; Wed, 3 Mar 2010 22:58:04 -0800 (PST)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAE/ojkurR7Ht/2dsb2JhbACbE3OdeZhUhHwEgxc
X-IronPort-AV: E=Sophos;i="4.49,579,1262563200"; d="scan'208";a="305012454"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 04 Mar 2010 06:58:06 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o246w6CO013203; Thu, 4 Mar 2010 06:58:06 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Mar 2010 22:58:06 -0800
Received: from 10.32.246.212 ([10.32.246.212]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Thu, 4 Mar 2010 06:58:05 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Wed, 03 Mar 2010 22:58:28 -0800
From: Sri Gundavelli <sgundave@cisco.com>
To: Basavaraj.Patil@nokia.com, mext@ietf.org
Message-ID: <C7B49A14.3B062%sgundave@cisco.com>
Thread-Topic: [Int-area] Rethink on Mobile IPv6
Thread-Index: Acq66gOoUWTseQTmoUO8Px+IuYFs9gAfhPrL
In-Reply-To: <C7B3E2AE.5767%basavaraj.patil@nokia.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 04 Mar 2010 06:58:06.0013 (UTC) FILETIME=[0A784ED0:01CABB68]
Cc: int-area@ietf.org, rdroms@cisco.com
Subject: Re: [Int-area] Rethink on Mobile IPv6
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Mar 2010 06:58:12 -0000

Raj:

I agree with your point that IPsec support is one of the complex areas of
the Mobile IPv6 protocol definition. Lack of standardized interfaces to
IPsec module, the needed interactions between Mobile IPv6 and Ipsec modules,
never made the protocol an easy implementation. And the recent new
extension, Dual-stack Mobile IPv6 support, surely took the complexity to a
new level. Not to trivialize the efforts, the solution under the given
constraints is probably the best chosen approach. We can blame NAT Traversal
support, or may be its the nature of the requirement, but the resulting
protocol is an implementation nightmare and we cannot deny that.

However, I'm not sure if this is the sole reason for the lack of protocol
adoption. As I see it the issues are multifold.

1. We have not realized that the protocols we develop at IETF have zero
value, if the approaches are not aligned with the SDO interests and if there
is no adoption of those protocols.

2. We do not respond to the SDO needs in a time bound manner. We are taking
years to standardize and deliver a feature, and in the process we are
hurting the protocol adoption. Looking at NETEXT WG, after two years of
debate, we barely made any progress, leaving the 3GPP group confused, as
when the IETF will provide the needed solutions.

Bottom line, I agree with your argument principle, that if the SDO groups
have a true need for alternative security approaches, we need to realize
that and provide the needed solutions, and in a time bound manner. And if
that is indeed the issue. I do realize that there are some elements in the
protocol that are surely adding to the protocol complexity and we should
make efforts to simplify it. And above all, we need to make sure the design
approaches are aligned with the SDO interests, IMO, that is probably the
bigger issue.


Regards
Sri








On 3/3/10 7:55 AM, "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com>
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
> 
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area