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

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 22 Mar 2005 18:16:30 -0800 (PST)

Hi Jari,

Thanks for the detailed explanation.  Some comments are in-line.

> >Both scheme reduces handover delay compared to the base draft.
> >  
> >
> Yes, although their primary intent is to reduce
> different components of the delay and overhead. Namely, CBA
> helps with being able to send traffic while care-of test
> is still going on, and CGA helps removes most home
> address tests. Both can impact latency, although CGA
> impacts also number of messages. Finally, CGA impacts
> signaling even when you are at the same location, whereas
> CBA helps only if you have an actual movement.
> 

OK.

> >
> >So how about having EBU/CBA with optional CGA key exchange for
> >extra security ? If we can save Home address test exchange for
> >the handover - we can save time there.
> >
> >  
> >
> The last paragraph more or less what I had in mind (although
> both parts have to be optional in some sense). Basically,

Great.

> CGA and key exchange makes it possible to eliminate
> most home address tests. This is in fact a bit more necessary
> in EBU/CBA than in base RFC 3775, because in order
> to reduce latency, you'd either want to have a home keygen
> token handy just in case you move soon (more signaling)
> or do it faster when you have moved. CGA + Key
> eliminate the need for this. Some could argue that the
> home test roundtrip is typically longer than care-of
> test roundtrip.
> 

Ok. I see that CGA + key actually has benefit for not doing
home-address tests for frequent movement. 

> Re: additional pre-binding messages. All of the current
> proposals for RR enhancements have some added signaling
> somewhere. RFC 3775 RR is rather stateless in the sense
> that when you move, you always do everything. CGA + Key
> approach basically involves a one-time setup cost, after
> which subsequent movements have a cost that is 50%
> of the RFC 3775 cost. All long data items are sent only in
> the initial setup messages. Whether all this makes sense depends
> primarily on the number of Binding Updates -- however its
> good to remember that in RFC 3775 you have to send Binding

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

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.

Regards,
-Samita

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 23 Mar 2005 06:55:49 +0200

>only once during first movement ?

Only once, when the mobile node and correspondent
exchange their first BU.

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

>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

---

From: Christian Vogt <[email-masked]>
Date: Wed, 23 Mar 2005 17:32:28 +0100

Hi Samita, hi Jari.

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

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