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

[Wassim Haddad <[e-mail]>]

Please note that one of OMIPv6 features is actually the same one  
offered by EBU.
BUT OMIPv6 is *more* secure, *eliminates* the HoTI/HoT and offers you a  
long
lifetime Kbm.


Regards,
Wassim H.


On 16-Mar-05, at 2:36 PM, Christian Vogt wrote:

> 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 <[e-mail]>:
>
>> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mipshop
>
Regards,

Wassim H.

_______________________________________________
Mipshop mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mipshop