Subject: Re: [Mip6] Re: RFC 4877 and the K bit

From: Sebastien Decugis <[email-masked]>
Date: Wed, 26 Sep 2007 09:41:58 +0900

Hi *,

I have a couple of questions regarding this 'K' bit.

In this thread:

- Francis told: "In the case of IKEv2 the solution
is very simple: only implement and support the K=1 case, and keep the K
bit only to detect configuration errors (as the K bit cannot be used
in practice to negociate something because nobody knows what to do when
it does not match  :-) )."

- Vijay told: "I would say it is better not to assume that the 
administrator will always pair mobile nodes that are capable of 
supporting the 'K' bit with home agents that are capable of supporting 
the 'K' bit."

Maybe it would close the debate to specify exactly what should happen in 
the case where MN or HA does not support the "Moving IKE_SA feature"?

In particular, from an implementor point of view, I don't know what is 
the expected behavior in the following situations:

-> On the MN, we have sent a BU with K=1, then received a BA with K=0. 
Then the MN moves.
=> Do the MN updates its tunnel-mode SPD entries to the new CoA? and SA?
=> Do we flush the IKE_SA (and associated CHILD_SA)? In that case, how 
the HA is notified of the flush?
=> Since the IKE_SA is broken, what happens if HA needs to send an IKE 
message?

-> On the HA, we have received a BU with K=0, and sent BA with K=0 (even 
if we do support the feature). Then, we receive a new BU from the same MN.
=> Do we update the tunnel-mode SPD entries ? and SA? Do we flush the 
IKE_SA?

In case it is not possible to answer these questions, then my opinion is 
that the K bit should be deprecated (at least in IKEv2 case) and the 
support for moving the IKE_SA be made mandatory. Otherwise, the expected 
behavior should be clarified. In any case, the communication between 
MIPv6 component and KMP component, for updating the IKE_SA, should be 
standardized.

Thanks for reading,
Sebastien.
-- 
Sebastien Decugis
http://www.nautilus6.org

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

---

From: <[email-masked]>
Date: Wed, 26 Sep 2007 10:28:46 +0200

My view of what should happen.  See inline. 

> -----Original Message-----
> From: Sebastien Decugis [mailto:[email-masked]] 
> Sent: 26. september 2007 02:42
> To: [email-masked]
> Subject: Re: [Mip6] Re: RFC 4877 and the K bit
> 
> Hi *,
> 
> - Francis told: "In the case of IKEv2 the solution is very 
> simple: only implement and support the K=1 case, and keep the 
> K bit only to detect configuration errors (as the K bit 
> cannot be used in practice to negociate something because 
> nobody knows what to do when it does not match  :-) )."
> 
> - Vijay told: "I would say it is better not to assume that 
> the administrator will always pair mobile nodes that are 
> capable of supporting the 'K' bit with home agents that are 
> capable of supporting the 'K' bit."
> 
> Maybe it would close the debate to specify exactly what 
> should happen in the case where MN or HA does not support the 
> "Moving IKE_SA feature"?
> 
> In particular, from an implementor point of view, I don't 
> know what is the expected behavior in the following situations:
> 

No.  The MN was told the peer could not move, so the MN must not
use the move functionality (even though it is supported).

> => Do we flush the IKE_SA (and associated CHILD_SA)? In that 
> case, how the HA is notified of the flush?

Yes, the MN flushes the IKE_SA and the CHILD_SAs.  The HA cannot
be notified.  The HA discovers the IKE_SA is broken because dead
peer detection fails.  Or the HA takes part in establishing a
new IKE_SA from a MN with the same identity as the previous IKE_SA.

> => Since the IKE_SA is broken, what happens if HA needs to 
> send an IKE message?

The HA will do exponential backup and finally realize the other end
is dead.

> => Do we update the tunnel-mode SPD entries ? and SA? Do we 
> flush the IKE_SA?

No, the MN said it could not move.  Then the HA must not move
either.  The question is how the new BU is protected.  Either the
ESP transport continues to live in the MN even though the end
point has a new address.  Or the IKE is established, and the
new ESP transport is used to send the BU.

Christian