Subject: [Mip6] RFC 4877 and the K bit

From: <[email-masked]>
Date: Fri, 21 Sep 2007 12:12:21 +0200

The K bit, when set, is used to indicate, that the end points of IKE can
be
changed dynamically.  RFC 3775 states in section 6.1.7, that if the K
bit
is cleared, and thus the IKE end points cannot be changed, still the
IPsec
SAs are expected to survive.  This is non-standard IKE behavior. (The
standard IKE behavior is this: deletion of an IKE SA also deletes all
the
CHILD SAs negotiated under that IKE SA.)

RFC 3775 is updated by RFC 4877.  RFC 4877 is close to specifying
the standard IKE behavior.  RFC 4877 speaks about the K bit in two
places: 
in section 4.4 third bullet which almost says IPsec SAs and the IKE SA 
must be moved both or must be re-established both, whereas section 7.4 
last sentence only talks about the IKE SA needing to be re-established.

Thus, if standard IKE behavior is expected, it would have been nice
with a statement saying if the K bit is set, then an IKE SA and its 
CHILD SAs are all moved, whereas if the K bit is clear, then an IKE SA 
and its CHILD SAs are removed when the address changes and must be
re-established.  

Thus RFC 3775 declares some kind of non-standardness of IKE,
whereas its successor RFC 4877 declares stadardness of IKE.

If standard IKE behavior is expected, this has the following
consequence.  
Suppose the mobile node uses IKE, and this IKE has negotiated the ESP 
transport to protect the binding updates.  Suppose further the mobile 
node is unable to move the IKE end point. Thus the mobile node clears 
the K bit.  When the mobile node comes to visit a new IPv6 network, 
it is assigned a new IPv6 care-of address.  Because it has a new 
care-of address, then it knows the IKE session is no longer valid 
(and have to be negotiated soon), and because it is no longer valid, all
IPsec SAs negotiated by the IKE are invalid.  This means, that the ESP 
transport to protect the binding update is no longer valid.

I suggest it is stated somewhere, that non-standard IKE behavior is 
expected: even though the IKE cannot be moved, the ESP transport
for the binding updates negotiated under IKE is expected to survive.
What does survive then mean?  Either it means the ESP transport becomes 
a CHILD SA under the next IKE SA being established and such a feature 
of attaching an already living CHILD SA to a new IKE SA is non-standard,
or it means the ESP transport may be used for the binding updates only,
but a new one must be negotiated under the new IKE SA.

Christian

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

---

From: Francis Dupont <[email-masked]>
Date: Fri, 21 Sep 2007 13:32:04 +0200

In your previous mail you wrote:

   The K bit, when set, is used to indicate, that the end points of
   IKE can be changed dynamically.  RFC 3775 states in section 6.1.7,
   that if the K bit is cleared, and thus the IKE end points cannot be
   changed, still the IPsec SAs are expected to survive.  This is
   non-standard IKE behavior. (The standard IKE behavior is this:
   deletion of an IKE SA also deletes all the CHILD SAs negotiated under
   that IKE SA.)

=> the situation is very different between IKEv1 (the only known
version at the publication of RFC 3775 BTW :-) and IKEv2: your "standard"
behavior applies only to IKEv2 (and IMHO is the real improvement!).

=> RFC 4877 is about IKEv2 explicitly.

=> note the SPD needs to be updated too.

=> you have also the SADB MIGRATE I-D which explains how to move the
IKE SA (the IPsec SAs are moved by the kernel, the IKE SA itself can
be only moved by the IKE tool which is usually only a privileged user
application).

=> from the IKEv1/IKEv2 point of view this seems very logical.

=> note this is not a problem because it will expire so to do the whole
stuff from the beginning in parallel with the new care-of address works
even far from the optimum.

=> do you mean for IKEv1 or for IKEv2? 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 :-).

=> the standard (in the standard meaning :-) is just to survive until
it expires or DPD flushes the whole obsolete state.

Regards

[email-masked]

PS: have you a question for the K=1 at both sides case (the only case which
means something with IKEv2/RFC 4301/RFC 4877)?

---

From: <[email-masked]>
Date: Fri, 21 Sep 2007 13:50:00 +0200

Thanks for the clarification.  In case both ends have K=1 (and this
is the expected normal case), all is now clear.  In case one end says
or previously has said K=0, moving to a new place means IKEv2
should be established and negotiate an ESP transport, then the binding
update can be sent.

Christian  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 21. september 2007 13:32
> To: Kaas-Petersen Christian
> Cc: [email-masked]
> Subject: Re: [Mip6] RFC 4877 and the K bit 
> 
> 
> => the situation is very different between IKEv1 (the only 
> known version at the publication of RFC 3775 BTW :-) and 
> IKEv2: your "standard"
> => you have also the SADB MIGRATE I-D which explains how to 
> move the IKE SA (the IPsec SAs are moved by the kernel, the 
> IKE SA itself can be only moved by the IKE tool which is 
> usually only a privileged user application).
> 
> => note this is not a problem because it will expire so to do 
> the whole stuff from the beginning in parallel with the new 
> care-of address works even far from the optimum.
> 
> => do you mean for IKEv1 or for IKEv2? 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 :-).
> 
> => the standard (in the standard meaning :-) is just to 
> survive until it expires or DPD flushes the whole obsolete state.
> 
> Regards
> 
> PS: have you a question for the K=1 at both sides case (the 
> only case which means something with IKEv2/RFC 4301/RFC 4877)?
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 24 Sep 2007 11:20:22 -0700

[email-masked] wrote:
> is the expected normal case), all is now clear.  

Ok.

> In case one end says

Perhaps you could avoid deleting/invalidating the IKEv2 SA and the IPsec 
SA as soon as you move. You should still be able to send the binding 
update with the existing IPsec SA.

Vijay