Wenxiao He writes: ha-ipsec-02.txt says both HA and MN can initiate a
SA negotiation:

5.18 Rekeying Security Associations

   Step 1.  The mobile node and the home agent have existing security
   associations.  Either side may decide at any time that the security
   associations need to be rekeyed, for instance, because the
   specified lifetime is approaching.

If HA is the one initiates the SA negotiation and phase 1 SA does not
surrive movement, HA needs to re-negotiate phase 1 SA. IKE then needs
to know MN's current Co@ to send IKE packets. If I did not miss
anything then either an API is required to retrieve this info from
BCE, or we can avoid this situation by stating something like "MN MUST
initiate SA negotiation".

------------

You are right in the sense that if phase 1
didn't survive and you moved, HA IKE is left
unable to reneg until phase 1 is brought up
again.

It seems to be so that if phase 1 does not
survive, its the mobile node who has to
initiate. Right now, the spec says both
sides must disconnect the existing phase 1,
and that the MN MAY try to reconnect.
Wouldn't that be enough? The only other
alternative appears to be requiring the MN
to initiate. That would be too drastic in
my opinion. 

So, what happens if the MN does not initiate?
There is no IKE connction, so what if the HA
wants to rekey SAs? Apparently, it would
try to re-establish phase 1 to ... at least
in our IPsec implementation to the current
gateway address, i.e. the current care-of
address. This appears correct?

------------

Wenxiao He responds to Jari Arkko:

> Wouldn't that be enough? The only other
> alternative appears to be requiring the MN
> to initiate. That would be too drastic in
> my opinion.

The requirement is too drastic but it would
help the operation. However, since "K" bit
already requires an API between MIP6 module
and IKE module, a similar API can be used
to get current Co@ for IKE.

So the suggestion is just to mention such an API in
ha-ipsec-02.txt for those whose IKE module
and MIPv6 module are not tightly integrated.

> So, what happens if the MN does not initiate?
> There is no IKE connction, so what if the HA
> wants to rekey SAs? Apparently, it would
> try to re-establish phase 1 to ... at least
> in our IPsec implementation to the current
> gateway address, i.e. the current care-of
> address. This appears correct?

Send to current Co@ should be fine.

------------

Jari Arkko writes: This issue is about which side initiates IKE after
movements.  If phase 1 can survive, then we are fine. However, it it
does not survive there's a question of who initiates and when. The
following possibilities exist:

  (a) MN always initiates, immediately.
  (b) MN always initiates, when it feels like it.
  (c-d) As above for the HA
  (e) Either side initiates, whenever there's a need.

What Wenxioa asks is how the HA knows where to send
the IKE packets, if its the HA that initiates. There
seems to be the following cases:

  (i) The MN moved, didn't send a BU yet. Nothing
      can be done here...
 (ii) The MN told the HA, but HA's IKE doesn't know.
      The connection will be sent to the previously
      used address, and it fails.
(iii) The MN told the HA, and IKE asks the MIPv6
      module for the current coa when initiating 
      connections. This works.

Ok, so at first it seems (iii) is the way to go.
However, there's a problem in the assumptions.
(iii) requires an API. However, if an API exists,
then I believe it should be used for moving the
IKE end-point, not for improving what is already
a bad solution imho i.e. renegotiations upon
movements. If no API exists, nothing can be done
anyway.

In conclusion, I think the K bit and its API
are sufficient, and we don't need to change the
spec.

------------

------------

------------

------------