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

From: [email-masked] (Arnaud Ebalard)
Date: Fri, 21 Sep 2007 17:07:01 +0200

Hi,

<[email-masked]> writes:

> 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.

About K bit, it might be good to go a little deeper in the
discussion. If we consider all the cases that can happen between a MN  
and its HA regarding movement support in the KMP on both sides (value
are K bit advertised on both ends), you get that:

MN HA

0  0  : no dynamic keying. K bit is useless (but works)

0  1  : this means that the KMP on the MN does not survive movement. To
        even get the K-bit exchange, this means that the SA must have
        been negotiated, which implies some bootstrapping mechanism is
        implemented, i.e. that the KMP behavior has been modified to
        support MIPv6 to some extent. In current context, this means
        that the KMP supports SADB_X_EXT_PACKET extension but not
        MIGRATE. All KMP implementations i'm aware of currently have
        both (racoon, racoon2), even if available externally. IMHO, this
        situation does not make that much sense. Basically, if the KMP
        has not been touched to add some MIPv6 support on the MN,
        speaking of K bit does not make sense.

1  1  : Everything is fine, K bit is useless.

1  0  : This is the interesting case. MN has a KMP that supports movement
        and certainly bootstrapping. Considering the fact that a trust
        relationship exists between the two entities, that they both
        require configuration by some administrator for the MIPv6 part
        and the KMP part, it seems weird to me that this administrator
        that want to provide mobility to the user will provide movement
        capable KMP on the MNs but will end up using HA that do not
        deliver such a service (considering all other efforts to setup
        and maintain stuff and the poor service that will result). 

        This is all the more weird if you consider that the HA _is_ able
        to support movement w.r.t. to kernel-maintained SP/SA 
        (i.e. MIGRATE is implemented in the kernel and will be used to
        move tunnel endpoints). The standards expect that behavior. This
        would mean that the kernel part has been patched to support the
        mechanism while a more accessible userland (the KMP) part has
        not. 

        Anyway, let's suppose it does. Let's also pass the fact that the
        K bit value is not available before the IKE negotiation is
        started but only after receiving the BA on the MN.

        When the MIPv6 process receives the information, no specific
        mechanism exists yet to pass that value to the KMP and even if
        that existed, the precise behavior of the KMP is not
        described. Also not that there are no means for the KMP on the
        HA not to send packets to an old address where the MN is no
        more, if it has to. 

The conclusion is that K-bit makes little sense in only one specific
case, which is very unlikely to happen. And even in that case, the
notification part between the MIPv6 process and the KMP has never been
defined. If the K-bit looked like a good idea to help solving future
MIPv6/IKE relationship when the standard was published, it is in
practice not usable. 

In fact, instead of adding code and developing new interfaces between
MIPv6 process and the KMP (which will require patching the KMP in all
cases), it would probably better to consider that:

 - To have IPsec protected communications using IKE with MIPv6 (meaning
   bootstrapping on the MN and movement support on both), one need KMP
   on _both_ ends to be patched to support mobility.
 - K-bit should be deprecated and rationale should be given.

The implications would be more simple relationships and less
developments. This would also prevent a lot of debugging issues, because 
this would simply prevent 0-1 and 1-0 situations to exist.

Please, even if they reflect my feelings on K-bit do not consider that
previous statements are some quick reaction. They result from long
discussions with technical people (at usagi) and quite a lot of time
spent on umip, racoon and Linux kernel code implementing related
features (SADB_X_EXT_PACKET, MIGRATE, ...). 

Comments welcome.

Regards,

a+

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

---

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

>         speaking of K bit does not make sense.

It is the mobile node that first sets the 'K' bit in the binding update. 
If the mobile node does not set it, the home agent should not set it 
either, since it already knows that the mobile node does not support it. 
So this should not happen in practice.

> 1  1  : Everything is fine, K bit is useless.

No. You still need both ends agreeing to "move" the IKEv2 SA to the new 
care-of address at the end of the binding update/binding ack exchange. 
You don't want this "move" to happen transparently.

>         and certainly bootstrapping. 

It is not clear to me how bootstrapping figures here. Maybe I am missing 
something.

> Considering the fact that a trust

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. Explicit 
indication in the BU/BAck is preferable.

>    on _both_ ends to be patched to support mobility.

If all MIPv6 mobile nodes and home agents support updating the IKEv2 SA 
using BU/BAck exchange, then of course there is no need for the 'K' bit. 
But we didn't want to assume this. So thats why the 'K' bit is there.

Vijay

---

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 24 Sep 2007 22:05:57 +0200

Hi Vijay, Hi *,

Vijay Devarapalli <[email-masked]> writes:

> It is the mobile node that first sets the 'K' bit in the binding
> update. If the mobile node does not set it, the home agent should not
> set it either, since it already knows that the mobile node does not
> support it. So this should not happen in practice.

In fact, no matter the value sent back by the HA in its BA when the MN
sends a BU with a K=0 value. In all cases, KMP will not be able to do
anything w.r.t. to received value for multiple reasons: 

1) KMP on the MN is not MIPv6-aware (it's not even sure it will be able
   to bootstrap, i.e. negotiate SA for the HoA using the CoA).
2) There is no defined mechanism to pass K bit value received by the
   MIPv6 process to the KMP
3) ... 

Anyway, without considering the values used during the exchange, can you
comment the description i gave in my first post (kept before my
reply). There is meaning in the last sentence.

> No. You still need both ends agreeing to "move" the IKEv2 SA to the
> new care-of address at the end of the binding update/binding ack
> exchange. You don't want this "move" to happen transparently.

What you say is that there are some cases where someone will configure
one side to have everything been renegotiated: it's time consuming,
power consuming. From my perspective (i.e. i might have misunderstood
the idea), the K bit was defined to detect a lack of the implementation
on one side. Here, it seems you consider K-bit as a feature. Perhaps
have i missed real life cases where this would be useful. Can you
provide some examples? 

> It is not clear to me how bootstrapping figures here. Maybe I am
> missing something.

When the MN sends its BU, it matches the policy, triggers an ACQUIRE
which is processed by the KMP. At that moment, HoA found in the SP (and
will be found in the SA) is not available yet and the CoA (or another
address, there are discussions on that topic too) must be used for
negotiating the SA (see draft-sugimoto-mip6-pfkey-migrate, and more
precisely the SADB_X_EXT_PACKET extension purpose). 

> always pair mobile nodes that are capable of supporting the 'K' bit
> with home agents that are capable of supporting the 'K' bit. Explicit

Patched KMP on the MN is a requirement so the only remaining question is
the implementation on the HA. If you look again the arguments in my
previous post, considering a limited implementation on the HA simply
does not make sense. 

> If all MIPv6 mobile nodes and home agents support updating the IKEv2
> SA using BU/BAck exchange, then of course there is no need for the 'K'
> bit. 

ok.

> But we didn't want to assume this. 

I understand but it seems that we do not have to assume anymore. The MN
can't even negotiate the initial transport mode SA for protecting the
BU/BA exchanged if its KMP is not patched to support MIPv6. As stated in
my previous post, I agree that the initial assumption was fair during the
design of MIPv6 but we now have more feedback and it just seems this
assumption does not hold anymore.

Regards,

a+

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 24 Sep 2007 14:49:14 -0700

> reply). There is meaning in the last sentence.

We don't have anything today in the MIPv6 bootstrapping mechanisms to 
allow a MN to bootstrap a HA that is capable of updating the IKEv2 SAs 
with the new care-of address.

> have i missed real life cases where this would be useful. Can you

You seem to be assuming certain controlled environments, for example an 
operator's mobile network, where MIPv6 is defined. It is perhaps 
possible in such networks to make sure all the nodes (mobile nodes and 
the home agents) support a certain feature. There should always be 
protocol extensions that will help in figuring out if the other end 
supports a particular extension.

> BU/BA exchanged if its KMP is not patched to support MIPv6. 

There is a difference between the IKEv2 being patched to support MIPv6 
from the IKEv2 allowing MIPv6 to update the IKEv2 SA. The current 
assumption is that there might be IKEv2 implementations that do not 
allow anyone else to update the SAs. I didn't see anything in your 
emails so far to change that assumption.

Vijay

As stated in

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 25 Sep 2007 00:22:54 +0200

Hi Vijay, Hi *,

> with the new care-of address.

I don't know if we give the same meaning to "bootstrapping". In the
context of dynamic keying, SADB_X_EXT_PACKET provides that. The issues
associated with it (difficult to implement in practice, among others)
and also with MIGRATE (IKE_SA update for transport mode  
when there is no tunnel mode SP/SA, ...) are currently being discussed
with the people of USAGI (Sugimoto-san, Sébastien Decugis and
others). At the moment, we are considering small design changes on
MIGRATE to solve _all_ the issues in an elegant fashion. If it gives
something we will perhaps end up updating MIGRATE draft.

> You seem to be assuming certain controlled environments, for example
> an operator's mobile network, where MIPv6 is defined. It is perhaps

Nope, i don't expect such environment. The only assumption i make is
that the MN and the HA are configured to use dynamic keying. Nothing
more. Then, i just list the requirements to have things happening. My
conclusion is that you have to have a patched KMP on the MN and
that non-patched KMP on the HA is simply non-sensical because, for
instance, the HA already has a patched kernel to support in-kernel
migration of SP/SA based on MIPv6 process stimulus (MIGRATE).

> emails so far to change that assumption.

Yes, there is nothing against the assumption in my posts. The main
reason is there is no need to provide that. Again, what would it be
useful for? I asked in previous email, is there any concrete example of
a use for that "feature"?  I think if someone clarifies that, this would
be helpful.

Last question: what is the expected way for the MIPv6 process to warn
the KMP? From my perspective, that part of the bridge between MIPv6 and
IKE is still missing.

Regards,

a+