Subject: Re: [MEXT] Text for Binding Update Race condition issue

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 06 Apr 2009 15:38:18 -0700

Hello Vijay,

I think that the proper home for the text you contributed is in
section 10.3.2.  Primary Care-of Address De-Registration.

Unfortunately, it isn't very natural to drop the text in directly as
given without any changes.  I thought it would be best to rearrange
the text a bit, essentially putting all of the text for handling the
deferred BCE removal after the description for sending the
Binding Acknowledgement.

Here is the result:

========================================================================

   A Binding Update is validated and authorized in the manner described
   in the previous section; note that when the mobile node de-registers
   when it is at home, it MAY choose to omit the Home Address destination
   option, in which case the mobile node's home address is the source IP
   address of the de-registration Binding Update.  This section
   describes the processing of a valid Binding Update that requests the
   receiving node to no longer serve as its home agent, de-registering
   its primary care-of address.

   To begin processing the Binding Update, the home agent MUST perform
   the following test:

   o  If the receiving node has no entry marked as a home registration
      in its Binding Cache for this mobile node, then this node MUST
      reject the Binding Update and SHOULD return a Binding
      Acknowledgement to the mobile node, in which the Status field is
      set to 133 (not home agent for this mobile node).

   If the home agent does not reject the Binding Update as described
   above, then the home agent MUST return a Binding Acknowledgement
   to the mobile node, constructed as follows:

   o  The Status field MUST be set to a value 0, indicating success.

   o  The Key Management Mobility Capability (K) bit is set or cleared
      and actions based on its value are performed as described in the
      previous section.  The mobile node's home address is used as its
      new care-of address for the purposes of moving the key management
      connection to a new endpoint.

   o  The Sequence Number field MUST be copied from the Sequence Number
      given in the Binding Update.

   o  The Lifetime field MUST be set to zero.

   o  The Binding Refresh Advice mobility option MUST be omitted.

   The rules for selecting the Destination IP address (and, if required,
   routing header construction) for the Binding Acknowledgement to the
   mobile node are the same as in the previous section.  When the Status
   field in the Binding Acknowledgement is greater than or equal to 128
   and the Source Address of the Binding Update is on the home link, the
   home agent MUST send it to the mobile node's link layer address
   (retrieved either from the Binding Update or through Neighbor
   Solicitation).

   When a mobile node sends a binding update to refresh the binding
   from the visited link and soon after moves to the home link and
   sends a de-registration binding update, a race condition can
   happen if the first binding update gets delayed. The delayed
   binding update can cause the home agent to create a new binding
   cache entry for a mobile node that had just attached to the home
   link and successfully deleted the binding. This would prevent the
   mobile node from using its home address from the home link.
 
   In order to prevent this, the home agent SHOULD NOT remove the
   binding cache entry immediately after receiving the deregistration
   binding update from the mobile node. It SHOULD mark the binding
   cache entry as invalid, and MUST stop intercepting packets on the
   mobile node's home link that are addressed to the mobile node
   (Section 10.4.1). The home agent should wait for MAX_DELETE_BCE_TIMEOUT
   seconds before removing the binding cache entry completely. In the
   scenario described above, if the home agent receives the delayed
   binding update that the mobile node sent from the visited link, it
   would reject the message since the sequence number would be less
   than the last received deregistration binding update from the home
   link. The home agent would then send a Binding Acknowledgment with
   status '135' (Sequence number out of window) to the care of address
   on the visited link. The mobile node can continue using the home
   address from the home link.
 
========================================================

I also fixed a minor problem with wording in the section using
an ambiguous "may not".

Comments?

Regards,
Charlie P.

Vijay Devarapalli wrote:
> George Tsirtsis wrote:
>> Hi Vijay,
>>
>> The logic of the text is fine with me, thanks.
>>
>> I am not so sure about the 120sec timeout though...it sounds completly
>> over the top. This is supposed to catch packets that have been delayed
>> in reaching the HA. That should not  be much more than the max
>> half-RTT for the Internet. Typical values
>>  these days are usualy some hundreds of milliseconds, so a few seconds
>> would suffice as a MAX ... I would say no more than 10seconds.
>>
>> Thoughts?
>
> Agree. 10 seconds or less makes more sense for the default value.
>
> Vijay
>
>> George
>>
>> On Wed, Mar 25, 2009 at 10:30 PM, Vijay Devarapalli 
>> <[email-masked]> wrote:
>>> Hi Charlie,
>>>
>>> Here is some text that you could perhaps use for the issue you pointed
>>> out on slide 7 at
>>> http://www3.ietf.org/proceedings/09mar/slides/mext-0.ppt
>>>
>>>
>>>  When a mobile node sends a binding update to refresh the binding
>>>  from the visited link and soon after moves to the home link and
>>>  sends a de-registration binding update, a race condition can
>>>  happen if the first binding update gets delayed. The delayed
>>>  binding update can cause the home agent to create a new binding
>>>  cache entry for a mobile node that had just attached to the home
>>>  link and successfully deleted the binding. This would prevent the
>>>  mobile node from using its home address from the home link.
>>>
>>>  In order to prevent this, the home agent SHOULD NOT remove the
>>>  binding cache entry immediately after receiving the deregistration
>>>  binding update from the mobile node. It SHOULD mark the binding
>>>  cache entry as invalid, and stop proxying for the mobile node's
>>>  home address. The home agent should wait for MAX_DELETE_BCE_TIMEOUT
>>>  seconds before removing the binding cache entry completely. In the
>>>  scenario described above, if the home agent receives the delayed
>>>  binding update that the mobile node sent from the visited link, it
>>>  would reject the message since the sequence number would be less
>>>  than the last received deregistration binding update from the home
>>>  link. The home agent would then send a Binding Acknowledgment with
>>>  status '135' (Sequence number out of window) to the care of address
>>>  on the visited link. The mobile node can continue using the home
>>>  address from the home link.
>>>
>>>
>>>  MAX_DELETE_BCE_TIMEOUT           120 seconds
>>>
>>> I didn't try to figure out which section this text would go into.
>>>
>>> Feel free to modify the text.
>>>
>>> Vijay
>>>
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>
>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 6 Apr 2009 20:31:51 -0400

Hi Charlie,

It looks good.

Thanks
Vijay

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]] 
> Sent: Monday, April 06, 2009 3:38 PM
> To: Vijay Devarapalli
> Cc: mext
> Subject: Re: [MEXT] Text for Binding Update Race condition issue
> 
> 
> Hello Vijay,
>