Subject: [mobile-ip] possible race condition in MIP?

From: Girish Chandranmenon <[email-masked]>
Date: Mon, 25 Feb 2002 12:23:42 -0500

Hi!

Perhaps this situation had been discussed here before, but I couldn't 
find it in the archives. If it had been discussed before, please direct 
me to the correct articles(s).

It seems possible for a mobile node to get cut off from the network 
because of the misordering of registration requests at the home agent.

Here is the scenario:

Consider a mobile node with two interfaces, 1 & 2; and corresponding FAs 
FA1 and FA2.

1. intf 1 gets connected, and MN sends solicitation on intf 1, receives 
advt, sends registration request (RQ1) towards FA1. After that intf1 
gets disconnected.

2. intf 2 gets connected, and MN sends solicitation on intf 2, receives 
   advt, sends  registration request (RQ2) towards FA2.

3. RQ1 is delayed at FA1 or along the path to HA, and RQ2 reaches the HA 
first.

4. HA registers the MN, and replies with the message RPLY2.

5. MN receives RPLY2 and is happy with that since that is the reply for 
the latest request it sent out. Now MN believes that it is successfully 
registered with FA2, on interface 2.

6. RQ1 reaches HA, and HA registers the mobile again; this time with 
FA1. Since HA cannot determine the order of origination of request 
messages (unless we use time stamp based replay protection). HA replies 
with RPLY1, and it never reaches MN. (even if it reaches MN, it will 
reject that reply, since it was for an earlier request).

As a result, the traffic towards MN will be sent towards FA1, which 
cannot reach MN, since the interface 1 is disconnected. MN thinks it is 
successfully registered at FA2.

The spec talks about this possibility in the timestamp based replay 
protection. but this is very much possible for the other choices of 
replay protection as well.

Any thoughts on how this can be avoided?

[We cannot use a monotonically increasing sequence number in the ID 
field. If we do that, we need to have additional mechanisms to remember 
the last used sequence # before a reboot, and we have to worry about 
wrapping sequence #s. etc..]

Thanks,
Girish.