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

"Charles E. Perkins" <charles.perkins@earthlink.net> Wed, 03 March 2010 20:50 UTC

Return-Path: <charles.perkins@earthlink.net>
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 C50023A8AF5; Wed, 3 Mar 2010 12:50:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
X-Spam-Level:
X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619]
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 hvkpYFsQB1xV; Wed, 3 Mar 2010 12:50:40 -0800 (PST)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 987963A82F0; Wed, 3 Mar 2010 12:50:40 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=gbXxt234WDxn95bzrNJgkOEv95J327vfUwTApso/c6cvFcFzxG/ys7hm12rcV6VT; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [12.204.153.98] (helo=[10.166.254.154]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1NmvWj-0008EL-ET; Wed, 03 Mar 2010 15:50:41 -0500
Message-ID: <4B8ECB9F.3010702@earthlink.net>
Date: Wed, 03 Mar 2010 12:50:39 -0800
From: "Charles E. Perkins" <charles.perkins@earthlink.net>
Organization: Wichorus Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
To: Basavaraj.Patil@nokia.com
References: <C7B3E2AE.5767%basavaraj.patil@nokia.com>
In-Reply-To: <C7B3E2AE.5767%basavaraj.patil@nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f525c7e26b42f22d349efd48473c325d3a7350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 12.204.153.98
X-Mailman-Approved-At: Fri, 05 Mar 2010 05:14:08 -0800
Cc: rdroms@cisco.com, int-area@ietf.org, mext@ietf.org
Subject: Re: [Int-area] [MEXT] 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: Wed, 03 Mar 2010 20:50:41 -0000

Hello Basavaraj,

I also think we need to do some rethinking.

To be brief:
- I think we need to allow network operators to
   utilize security mechanisms they deem appropriate,
   whether or not standardized by the IETF.

- I think we need to allow network operators to
   utilize tunneling mechanisms they deem appropriate,
   whether or not standardized by the IETF.

I'm happy to break down the specification
into components (such as route optimization, etc.).
I'll even volunteer to hack the text.  But I do
not think this is a major stumbling block.
After all, the mobile node is the one initiating
route optimization.  If the home agent does not
support it, there is no route optimization --
in other words, this function is trivially
controllable by operators.

I'm concerned because I know that Mobile IP
offers very high-performance mobility management
and session persistence -- yet, in one SDO
after another we see suboptimal, slow signaling
for clunky interworking schemes that don't even
support VoIP very well.

Something is wrong.  I have a hard time believing
that the operators insist that their customers
cannot have the best available.  It's much more likely
that they don't see a comfortable evolutionary
path because of the limited security and tunneling
options available with RFC 3775.

Regards,
Charlie P.


On 3/3/2010 7:55 AM, 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
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>