Subject: RE: [seamoby] Single sentence problem statements

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sun, 4 Feb 2001 18:29:31 +0100

> > 
> > Pat ,our chair, has a firm grasp on this issue, since one of his main chores
> > as a WG chair is to avoid redundancy with other WGs.
> 
> Correct, and one of the co-authors of the v4 fast handoff work, so I am quite
> familiar with the ongoing work :)
> 
> I believe that the MM folks have raised some interesting questions about
> MIPv6's reliance on IPSec, and the fact that a fast handoff will require an
> IKE exchange. So, minimizing such exchanges will in fact provide the perceived
> fast handoff :) Of course, the MM folks could explain what they are doing much
> better than I could (I am just an observer).
> 
	=> We most certainly do not want the handover to require a new IKE
	exchange and I don't understand how it would. I'm surprised these 
	concerns were raised. The concerns are not valid because MIPv6 
	mandates that the SA be established based on the Home address. 
	Hence, when moving no new SAs are required to update the HA and 
	CNs. As for updating the previous AR, yes an SA is required but there 
	are two solutions we investigated in MIP to solve this :

	1. If you're using a flat mobility management model (no MAP)
	   then we were counting on SEAMOBY to transfer the SA
	   from the old AR to the new one. I think this is a very valid
	   solution. 

	2. If a MAP exists, the MN establishes an SA only when moving
	    between two MAP domains. Therefore the SA establishment
	    will be very rare, depending on the size of the MAP domain. In 
	    other words, depending on how many ARs are advertising a MAP
	    option. 

	As for IKE and whether it's too heavy, spectrum inefficient ..etc
	please have a look at draft-soliman-mobileip-routeopt--mipv6-00.txt 
	which proposes an alternative.

	Hesham

---

From: Michael Thomas <[email-masked]>
Date: Mon, 5 Feb 2001 16:28:15 -0800 (PST)

> 	   from the old AR to the new one. I think this is a very valid

I believe that *any* discussion of the ability to
transfer security context needs to be placed under
a giant microscope and evaluated with a jaundiced
eye. Transfering secret keys and security context
is not something that should be taken lightly.
I'm particularly vexed by the notion of
transfering IPsec SA's: it strikes me as a highly
dubious thing to do.

This is one area that I'd far prefer that if there
is a way to get this all to work in the usual way
(read: just recreating the SA), it should be 
considered.

 > 	which proposes an alternative.

This is _simpler_ than IKE? Yikes. Also: it looks
like you've managed to recreate the cross realm
Kerberos wheel with about 15 years less deployment
experience.

		Mike