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

[Christian Vogt <[e-mail]>]

Wassim Haddad wrote:
> 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.


Hi Wassim,

are you refering to CGA-OMIPv6?

It is true that CGA-OMIPv6 replaces the HoA test through the more secure
CGA mechanism.  But you still need to do the CoA test, so handover
latency may still be high.

OTOH, you could move the CoA test off the critical path by complementing
CGA-OMIPv6 with CBA (see Gabriel's mail).

- Christian


>> 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

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



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

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