Re: RR enhancements (Was: Re: [Mipshop] MIPSHOP discussion on new items and milestones)

[Christian Vogt <[e-mail]>]

Hi Samita, hi Jari.

 > All RO methods, including the RFC 3775 one, require
 > some state keeping. CBA/EBU needs at least the
 > counters, maybe some data related to the signaling
 > too. CGA/OMIP requires the shared key to be stored,
 > and lifetime of that key. These are short, the long data
 > items (public key) in the initial exchange are only needed

Our EBU implementation for the MN requires some state for periodic, 
proactive HoA tests, which we do on a periodic basis.  This is basically 
a timestamp in the binding-update-list entries.  You don't need it if L2 
triggers can be used to schedule the proactive HoA tests.

The simple-CBA implementation affects the CN only, where it adds an 
integer, the credit counter, to each binding-cache entry as well as a 
1-bit flag to differentiate between verified and unverified CoA's.

 > But as I have said before, I think the two schemes are
 > orthogonal, so I don't think we need to choose between
 > them. It appears quite possible to run both of them and
 > get both advantages. (This does not necessarily imply that
 > they have to be in one document, just that they both
 > exist in standardized form.)

I agree.  The HIP folks decided to to do something similar in 
Minneapolis.  They will integrate simple-CBA into HIP-based mobility and 
multi-homing there.  In fact, CBA can be seen as a *strategy* that 
applies to any mobility protocol (which uses IP-address tests).  One 
modification might be necessary with some mobility protocols, though. 
Namely, there needs to be an early, authenticated message that tells the 
CN about the MN's new CoA (or Locator, in HIP terminology).  This 
message already exists in HIP, but it does not exist in RFC 3775.  (See 
the threat with James, starting with [1].)

- Christian

[1] http://www1.ietf.org/mail-archive/web/mipshop/current/msg01119.html

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


Jari Arkko wrote:
> Samita Chakrabarti wrote:
> 
>> I assume then long Data items (CGA+Key, SIG etc.) need to be
>> sent with every movement with pre-binding update ? Or is it
>> only once during first movement ?
>>  
>>
> 
> Only once, when the mobile node and correspondent
> exchange their first BU.
> 
>> If we send pre-binding msgs everytime MN moves, then in CGA scheme we 
>> save signalling in HOT/HOTI tests - I agree that's
>> a good gain.
>>
>>  
>>
>>> Updates every couple of minutes. This can be eliminated
>>> with a longer home test lifetime, which CGA can provide.
>>> This can be important for battery lifetime and aggregated
>>> bandwidth in cellular networks.
>>>
>>>   
>>
>>
>> Agree.
>>
>>  
>>
>>> Some theoretical calculations about the impacts of
>>> different methods can be found in Section 9 of
>>> draft-haddad-mip6-cga-omipv6-03.txt. For instance,
>>> a stationary mobile node (sounds funny but its really
>>> a quite common case) gets upto a 200-fold decrease
>>> in amount of signaling packets.
>>>
>>>   
>>
>>
>> Ok. Thanks.
>>
>>  
>>
>>> So, we could compare the two approaches but at the
>>> end of the day, they optimize different parts, and the sum
>>> of those parts is what the user sees. It consists of both
>>> latency (care of test, home test, other things) and signaling
>>> overhead.
>>>   
>>
>>
>>
>> Also, in the design, we need to consider minimum state keeping at
>> the CN -  the base design does not require any
>> state keeping at CN - which is a nice feature. CBA/EBU requires
>> some state keeping. Does OMIP6 require state keeping at CN?
>>  
>>
> All RO methods, including the RFC 3775 one, require
> some state keeping. CBA/EBU needs at least the
> counters, maybe some data related to the signaling
> too. CGA/OMIP requires the shared key to be stored,
> and lifetime of that key. These are short, the long data
> items (public key) in the initial exchange are only needed
> temporarily to verify the shared key.
> 
>> Agree that reducing signaling overhead, protection of home-address 
>> from the
>> attacker and reachability tests are important. At the end, implementors
>> would like to see a relatively simple protocol to implement to
>> achieve all these things. I like the less signalling part in CGA+key
>> scheme and like the credit based lifetime in the CBA scheme becuase
>> it can be flexible for different types of applications, but the optimum
>> lifetime values may need to be tuned so that it generates less BU for
>> such apps.
>> I see its not trivial to choose one draft over the other or merge them 
>> to obtain the maximum benefit.
>>  
>>
> Choosing might be difficult, because people may have
> differerent objectives in mind. For instance, I care a lot
> about "stationary" mobile nodes and the amount of
> overhead signaling they care. Others may care more about
> latency.
> 
> But as I have said before, I think the two schemes are
> orthogonal, so I don't think we need to choose between
> them. It appears quite possible to run both of them and
> get both advantages. (This does not necessarily imply that
> they have to be in one document, just that they both
> exist in standardized form.)
> 
> --Jari


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