Re: [Mipshop] MIPSHOP discussion on new items and milestones

Christian Vogt <chvogt@tm.uka.de> Wed, 16 March 2005 19:40 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28502 for <mipshop-web-archive@ietf.org>; Wed, 16 Mar 2005 14:40:28 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBeRg-0000wa-0F for mipshop-web-archive@ietf.org; Wed, 16 Mar 2005 14:44:44 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBeK9-0004ZI-FJ; Wed, 16 Mar 2005 14:36:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBeK7-0004ZD-56 for mipshop@megatron.ietf.org; Wed, 16 Mar 2005 14:36:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28206 for <mipshop@ietf.org>; Wed, 16 Mar 2005 14:36:53 -0500 (EST)
Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX190pWdwSfQEA8gmqf5+iIIprwqVa5KJ0/I=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBeOC-0000lX-Eh for mipshop@ietf.org; Wed, 16 Mar 2005 14:41:09 -0500
Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps (Exim 4.43 #1) id 1DBeJw-00060B-Co; Wed, 16 Mar 2005 20:36:52 +0100
Received: by smtp.ipv6.tm.uni-karlsruhe.de (Postfix, from userid 33) id 3E1AD178007; Wed, 16 Mar 2005 20:36:38 +0100 (CET)
Received: from 68.152.111.54 ([68.152.111.54]) by mail.tm.uni-karlsruhe.de (IMP) with HTTP for <chvogt@localhost>; Wed, 16 Mar 2005 20:36:38 +0100
Message-ID: <1111001798.42388ac632a05@mail.tm.uni-karlsruhe.de>
Date: Wed, 16 Mar 2005 20:36:38 +0100
From: Christian Vogt <chvogt@tm.uka.de>
To: gabriel montenegro <gab@sun.com>
Subject: Re: [Mipshop] MIPSHOP discussion on new items and milestones
References: <4238786E.9040202@sun.com>
In-Reply-To: <4238786E.9040202@sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.6
X-Originating-IP: 68.152.111.54
X-Spam-Score: -2.6 (--)
X-Spam-Status: No
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48
Content-Transfer-Encoding: 8bit
Cc: mipshop@ietf.org, tm-ro2@tm.uka.de
X-BeenThere: mipshop@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mipshop.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mipshop@ietf.org>
List-Help: <mailto:mipshop-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=subscribe>
Sender: mipshop-bounces@ietf.org
Errors-To: mipshop-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92
Content-Transfer-Encoding: 8bit

Hi Gabriel, hi all.

> - EBU - but have heard concern that this *increases* signaling cuz it
> adds messages, what we want is less (not more) signaling.

I heard about these concerns.  Indeed, there are two ways in which EBU
increase signaling:  through the proactive HoA test (if done on a
periodic basis) and through the additional EBU/EBA messages.  Both can
be mitigated, however.

(i) Proactive HoA tests

When the proactive HoA test is done on a periodic basis, it needs to be
done every 3.5 minutes.  (3.5 minutes is the lifetime of the Home Keygen
Token.)  Roughly speaking, this causes additional signaling only when
the mobile node moves less often than every 3.5 minutes.  And for such
"low-mobility" scenarios, one can use [1] to reduce the signaling
overhead of Mobile IPv6 both with and without proactive HoA tests.

[1]
http://www.watersprings.org/pub/id/draft-arkko-mipv6-binding-lifetime-extension-00.txt

(ii) Additional messages

The EBU/EBA messages are exchanged in parallel to the CoTI/CoT messages.
 So some folks have suggested to combine the EBU with the CoTI as well
as combining the EBA with the CoT.  This is certainly possible and would
eliminate the additional signaling.

Of course, we had thought about the benefits of combining messages when
we wrote the initial EBU draft.  The rationale for using separate
EBU/EBA messages back then was to modify as little as possible from the
base specification.  But as folks start to become concerned about the
additional signaling, yes, we can integrate the EBU/EBA messages with
the existing CoTI/CoT messages.

Still, one also needs to consider that separate EBU/EBA messages have
advantages, too.  One such advantage is backward compatibility:  If a CN
does not understand an EBU message, and the EBU and CoTI messages are
separate, the CN can just drop the EBU and respond to the CoTI.  Another
advantage comes into play when combining EBU with direct signaling [2].
 There was a discussion on this on the Mobopts mailing list shortly
before IETF 62.

[2]
http://www.ietf.org/internet-drafts/draft-ewu-mobopts-directsig-00.txt

- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/


Quoting gabriel montenegro <gab@sun.com>:

> Folks,
>
> As you may be aware, the working group's current milestones are
> all done.
>
> I spoke with Margaret Wasserman (taking over from Thomas Narten
> as our advising AD) during IETF week, about possible next steps
> for MIPSHOP.
>
> It seems like there is sufficient interest and plenty of potential
> work items to keep the working group going. Possible items
> Margaret and I talked about include the following areas:
>
> Further work on FMIPv6
> ----------------------
>
> - work on MN-AR security. For example:
>
>    - AAA-based keys for handovers - the need/desirability for such
> 	an item was brought out in Jari's presentation in MOBOPTS.
> 	even though this item does not yet exist in the form of
> 	an I-D, it seems we should not have major difficulties
> 	identifying interested parties to work on it.
> 	This item is limited in terms of the deployment scenarios
> 	it supports, but the carrier/service provider scenario it
> 	caters to seems important enough to warrant work on it.
> 	perhaps for PS?
>
>    - derive key from SeND for fmip (Rajeev/Kempf draft)
> 	despite the IPR implications because of the use
> 	of CGA (from SeND), this could target PS
>
> - work on FMIPv6 itself:
>
>    - The above items will go a long way towards solving the security
> 	issues in FMIPv6. The current lack of such solutions is
> 	perhaps the major issue why FMIP is currently experimental
> 	and not PS. Given the above items, the WG could also take
> 	on the effort to revise the base FMIP to PS. This effort
> 	will clearly benefit from the fact that there are several
> 	implementations of FMIPv6 (including publicly available
> 	ones), so feedback from these effort will surely help in
> 	cleaning it up towards PS.
>
>    - Apparently, the CDMA folks (in particular, those working
> 	on "1x-EV evolution" have some interest in using FMIPv6.
> 	Another potential WG item could be a document to describe
> 	how FMIPv6 would work over such a link. This document
> 	would be analogous to our current FMIPv6 over 802.11
> 	document, and would similarly target informational.
>
> RR optimizations
> ----------------
> I must confess to me these seem less coherent and ready as a group
> than
> the above group. E.g., it's not clear to me whether a standards-track
> document would end up mixing different proposals, and how.
>
> - CGA type idea from OMIP
> - CBA (credit-based) maybe no 'spot checks', just the basic stuff
> 	as is being applied to HIP, for example. this could complement
> 	other proposals like CGA or preconfigured MN-HA SA, for example.
> - EBU - but have heard concern that this *increases* signaling cuz it
> adds
> 	messages, what we want is less (not more) signaling.
>
> ----
>
> These are the two areas I see most probable for continued work.
> Nevertheless, there are other items people have mentioned. Feel
> free to propose additional items if you consider they are ready for
> standardization. This is diffucult to judge, but the following
> are things to keep in mind (of course, they are *not absolute
> requirements*):
>
> - are the proposals mature (e.g., plenty of discussion, several
> 	revisions taking into account WG feedback, published
> 	results, existing implementations, etc)
> - is there interest in the proposals (e.g., are folks interested
> 	in deploying, perhaps because the proposal enables certain
> 	scenarios, is there interest from *more than one party*, etc)
> - is IPR resolved (at least RAND as per IETF rules, hopefully
> 	royalty free of course)
>
> Items not ready *now* may of course be ready later on. In the
> meantime,
> those items may continue being discussed in other working/research
> groups,
> as individual submissions, etc.
>
> I have spoken with some of you about the above (thanks for the
> feedback).
> Even if you have privately expressed your opinions, please send your
> comments on the above items to the list. Besides expressions of
> support, negative opinions are equally important. I have purposely
> listed perhaps more items than we'll be able to take on, so we
> will probably have to cut the list a bit shorter. Hence, any
> comments to help in that respect are also very useful.
>
> So please consider the rechartering discussion for MIPSHOP open
> (hopefully the directions mentioned above are close enough).
>
> Comments?
>
> -gabriel


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop