Re: [Mobopts] MIPv6 IPsec Route Optimization (IRO)

arno@natisbad.org (Arnaud Ebalard) Mon, 17 November 2008 22:47 UTC

Return-Path: <mobopts-bounces@irtf.org>
X-Original-To: mobopts-archive@megatron.ietf.org
Delivered-To: ietfarch-mobopts-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A49F28C191; Mon, 17 Nov 2008 14:47:46 -0800 (PST)
X-Original-To: mobopts@core3.amsl.com
Delivered-To: mobopts@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B61028C172; Mon, 17 Nov 2008 14:47:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 SJI4rkdTvP01; Mon, 17 Nov 2008 14:47:42 -0800 (PST)
Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 80B713A6922; Mon, 17 Nov 2008 14:47:42 -0800 (PST)
Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <arno@natisbad.org>) id 1L2Csc-0003LC-9N; Mon, 17 Nov 2008 23:47:38 +0100
X-Hashcash: 1:20:081117:ipsec@ietf.org::5nr40BJfxY5+aE/9:0000k6B
From: arno@natisbad.org
To: "Haddad, Wassim Michel" <whaddad@qualcomm.com>
References: <C54744E3.6A58%whaddad@qualcomm.com>
X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc
X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026
X-Hashcash: 1:20:081117:mext@ietf.org::vI8uGZGwHWmdiCo8:00000+50
X-Hashcash: 1:20:081117:mobopts@irtf.org::6F9PKFB227oVUlps:030T6
X-Hashcash: 1:20:081117:whaddad@qualcomm.com::1904AmG5DqwOftse:000000000000000000000000000000000000000005ymi
Date: Mon, 17 Nov 2008 14:45:54 -0800
In-Reply-To: <C54744E3.6A58%whaddad@qualcomm.com> (Wassim Michel Haddad's message of "Mon, 17 Nov 2008 12:57:23 -0800")
Message-ID: <87r65adl99.fsf@natisbad.org>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Cc: IPsec IETF WG ML <ipsec@ietf.org>, Mobopts IRTF WG ML <mobopts@irtf.org>, IETF MEXT WG ML <mext@ietf.org>
Subject: Re: [Mobopts] MIPv6 IPsec Route Optimization (IRO)
X-BeenThere: mobopts@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobility Optimizations <mobopts.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=unsubscribe>
List-Archive: <https://www.irtf.org/mailman/private/mobopts>
List-Post: <mailto:mobopts@irtf.org>
List-Help: <mailto:mobopts-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mobopts-bounces@irtf.org
Errors-To: mobopts-bounces@irtf.org

Hi,

"Haddad, Wassim Michel" <whaddad@qualcomm.com> writes:

> I have just submitted a new I-D [1] which certainly requires an
> introduction (and disclaimer): it specifies a MIPv6 Route Optimization
> procedure *dedicated* to environments where IPsec/IKE is used between
> peers (MN-HA, MN-CN, MN-MN) for protecting both signaling and data
> traffic.
>
> Some of the improvements provided by this "IPsec Route Optimization"
> mechanism (IRO) are also proposed for the IPsec communications between
> the MN and its HA.
>
> Among the features provided by IRO (introduction of the document as
> a more accurate list):
>
>   * Complete removal of RH2 and HAO (resulting in simplified packet
>     handling on both sides and possibly better compatibility with
>     filtering implemented in the network),
>
> => You can have complete removal of both options without introducing a
> new RO mode.

Sure. But there are additional reasons (and advantages, as provided in
my previous list) to introduce a new RO mode. IMHO, those advantages are
worth the introduction. But I am interested on feedback about those
specific parts of my I-D.

> Please check
> http://www.ietf.org/internet-drafts/draft-haddad-mipshop-tunneling-optimization-01.txt 

I already read version -00. I basically took a look at all I-D and
reference documents associated with tunneling optimizations and MIPv6 RO 
(always in an IPsec context): ERO, BEET, RO design history, your draft
...

Your proposal may have an interest for the common RO case if one intend
to keep the RRP. I just don't. I am convinced that removing the
duplicated states and exchanges when IPsec/IKE are used in a MIPv6
context can provide a far better solution.

>From my perspective, I just don't feel the need to introduce additional
states and exchanges (the PaT) because those are already available
locally (and synchronized over time) on the IPsec/MIPv6 entities
(SA/Bindings). Obviously, this is only true for IPsec entities, which
are (as presented before) my targets.

Thanks for your comments.

Cheers,

a+

ps: note that my -00 lacks pictures to ease the understanding of what
    happens. That's on the todo list for -01.
_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www.irtf.org/mailman/listinfo/mobopts