Re: [MEXT] Review of draft-ietf-monami6-multiplecoa-13 + Proposals

arno@natisbad.org (Arnaud Ebalard) Wed, 20 May 2009 11:17 UTC

Return-Path: <arno@natisbad.org>
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ADC93A711E for <mext@core3.amsl.com>; Wed, 20 May 2009 04:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.588
X-Spam-Level:
X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 kGn3bKj12c-5 for <mext@core3.amsl.com>; Wed, 20 May 2009 04:17:39 -0700 (PDT)
Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 0FE3B3A7122 for <mext@ietf.org>; Wed, 20 May 2009 04:17:39 -0700 (PDT)
Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <arno@natisbad.org>) id 1M6jpF-0005fS-M8; Wed, 20 May 2009 13:19:09 +0200
X-Hashcash: 1:20:090520:mext@ietf.org::8YnXcJZw7C1w8irj:00007acQ
From: arno@natisbad.org
To: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
References: <C6305549.7554%vijay@wichorus.com> <87eiusx1s6.fsf@small.ssi.corp> <2D50B653-C7B4-4FDF-93A0-D7F0AE2BEEDC@gmail.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:090520:hesham@elevatemobile.com::URpb42xjA+tR5QKj:000000000000000000000000000000000000001yz
X-Hashcash: 1:20:090520:tsirtsis@googlemail.com::p08A/+O2jXXR/uK2:000000000000000000000000000000000000000++Q
X-Hashcash: 1:20:090520:marcelo@it.uc3m.es::T6FI37llF9syHdVc:00000000000000000000000000000000000000000002Ll7
X-Hashcash: 1:20:090520:vijay@wichorus.com::YyI28Wyqh92V50GG:00000000000000000000000000000000000000000000Nda
X-Hashcash: 1:20:090520:ryuji.wakikawa@gmail.com::NsY90kjwy8X17moq:00000000000000000000000000000000000001Rdq
X-Hashcash: 1:20:090520:thierry.ernst@inria.fr::geHlOnscybOJK+3e:000000000000000000000000000000000000000Kwae
Date: Wed, 20 May 2009 13:19:47 +0200
Message-ID: <87ws8cnhrg.fsf@small.ssi.corp>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: IETF MEXT WG ML <mext@ietf.org>
Subject: Re: [MEXT] Review of draft-ietf-monami6-multiplecoa-13 + Proposals
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 May 2009 11:17:40 -0000

Hi Ryuji,

>From the 4 main points I raised in my review, 3 have been clarified. 1
is IMHO still open. It is discussed after a summary of closed items (for
the records): 

 - Section 5.6, i.e. complex Home Link scenario w/o *explicit*
   rationale : 3GPP use case, described by Christian and Julien.

 - No ability to have traffic routed to the HoA : will be handled in
   flow-binding document.

 - Reuse of a single IPsec tunnel mode SA for traffic for all CoA:
   the hack is certainly difficult to implement but easier on RFC 4301
   compliant implementations. Thanks to Vijay for having coped w/ me on
   that one.

The last point regarding the reuse of K bit was still open so I took a
new look at what is in the draft. I'd like to clarify the expected
behavior for the common case.

The idea developed in section 9.1 of the draft is that the MN sends a
BU with K bit set *and* a single BID mobility option to update the CoA
which must be used by IKE. The HA receiving that BU will inform the IKE
daemon on its side with the CoA with the BID. 

The thing is that if the IKE module on the MN supports movement, K bit
will be set in all BU. It would not make sense ("MCoA keeps backward
compatible with 3775") but it is probably worth asking the question
before going further: does MCoA draft change that behavior?

Now, let's consider a MN whose IKE module supports movement (its HA
too). It will have K-bit set in all its BU. Let's say the MN currently 
has two CoA on different interfaces: CoA1 and CoA2 registered with its
HA. Each one is associated with a given BID. Let's consider CoA1 is
currently used for IKE traffic to the HA. Now, due to a handover, the MN
configures a new address instead of CoA2. CoA1 had not been modified so
the MN does not have to request an update of IKE address to the HA. But
the MN needs to warn its HA about the address change. It cannot send a
BU with K bit set and only the BID mobility option with the updated CoA2
value. How is this handled?

Cheers,

a+