Subject: RE: [mobile-ip] rerunning IKE, RR SA endpoint changes, and IPsec NAT-T

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sat, 4 Jan 2003 22:26:18 -0800

> 
> Mohan Parthasarathy wrote:
> >  Jari,
> > 
> > Just one observation. Some implementations may choose the 
> SPI unique across
> > all SAs so that it does not use the destination address to 
> lookup the SA. In
> > that
> > case you don't need to update at all.  But if this is not 
> true, then it
> > really
> > matters on how often the MN moves. But still updating SAs (it can be
> > expensive
> > in some architectures e.g. h/w acceleration card) might be 
> faster than
> > negotiating
> > new ones.
> 
> I agree that in some architectures the updates can be costly.
> In theory, SA creation and in particular key set-up is costly
> and other updates might be easier. If your crypto chip requires
> all of the SA parameters to be updated even if you change just
> the gateway address, this may delay you a bit. Or the
> chip-main CPU signaling path gives some latency for any updates.
> 
> When do we need to update? There seems to be two issues at
> play here: one, does the peer recognize our packet if it
> comes to a new address? And two, will the packet get to peer in
> the first place? Regarding the last issue, note that we are updating
> the gateway address in the IPsec SA. That is, the destination address
> in the outer tunnel header. Without an update to this address,
> the packets would be destined to the old care-of address. While
> the first issue can be solved with a relaxation of the SA lookup
> rules, the second issue is still relevant.
> 
Yes. Note that only in the MN, the SA is looked up using the new care
of address. SA lookup in HA is not a function of the new care of address.
But you still need the right care of address for packets reaching the
MN (outbound SA in HA needs the right value) as you mentioned above.
The same may not be true for the inbound packets as HA may not really
care about what is there in the outer IP header's source address.

> Of course, we have two ways to make an update: either update
> the SA or negotiate a new one through IKE. Do you have a
> suggestion on how we could allow both? There needs to be
> some interoperability between MNs and HAs from different
> vendors, which side will make the decision on what to do?
> Also, it isn't clear what the tradeoffs are e.g. MN
> sending more packets over wireless vs. home agent saving
> some CPU.
> 
> Oh well, it seems that in any we must be able to accept
> a reneg that the other side proposes. Is it enough to
> require a capability to modify SAs but allow implementations
> to do a reneg if they want to?
> 
I am not sure how bad it would be to use the BU to indicate what
the MN wishes to do and the HA can wish the same in BA back. When
the BU reaches HA, it knows what the MN would do (MN expresses this
using some bit in the BU). HA either decides to update SA(only if
MN has expressed to update SA also) or negotiate a new SA (even if
MN has expressed to update SA). When the BA comes back (HA sets a bit
in the BA), MN can look at the bit and decide. Not thought hard
enough. Comments ?

> Jari
-mohan