Re: [MEXT] New RFC3775bis issue "BU de-registration race condition"?

[Hesham Soliman <hesham at elevatemobile.com>]

> 
> There is some related text in RFC3776:
> 
>      "When the mobile node returns home and de-registers with the Home
>       Agent, the tunnel between the home agent and the mobile node's
>       care-of address is torn down.  The security policy entries, which
>       were used for protecting tunneled traffic between the mobile node
>       and the home agent MUST be made inactive (for instance, by
>       removing them and installing them back later through an API).  The
>       corresponding security associations could be kept as they are or
>       deleted depending on how they were created.  If the security
>       associations were created dynamically using IKE, they are
>       automatically deleted when they expire.  If the security
>       associations were created through manual configuration, they MUST
>       be retained and used later when the mobile node moves away from
>       home again.  The security associations protecting Binding Updates
>       and Acknowledgements, and prefix discovery SHOULD NOT be deleted
>       as they do not depend on care-of addresses and can be used again.
> 
> According to this the SAs protecting data traffic are torn down, but the
> SAs protecting MIP6 signaling traffic should not be deleted when MN is
> returning home.  

=> Right, so according to that and my previous email, the race condition
can't happen because the BU sent from the old foreign network will have an
old seq no.

Hesham


> 
> BR,
> 
> Kilian
> 
> 
>> -----Original Message-----
>> From: Conny Larsson [mailto:conny.larsson at ericsson.com]
>> Sent: Dienstag, 14. Oktober 2008 12:18
>> To: Kilian Weniger
>> Cc: mext at ietf.org
>> Subject: Re: [MEXT] New RFC3775bis issue "BU de-registration
>> race condition"?
>> 
>> Hi Kilian,
>> 
>> I had a quick look in RFC3775 and I agree that it's not clear
>> and most 
>> likely some clarifications would be good. However, I thought
>> about the 
>> SA established between the MN and the HA. When the BCE is
>> deleted does 
>> the SA go away as well? In case of static SAs I guess they
>> remain but in 
>> case of dynamic SA establishment they could have been deleted and in
>> that case the delayed BU would not be accepted and an ICMP
>> message would 
>> be sent back to the MN. I need to look a bit more into RFC3775 to
>> understand it better ...
>> 
>> Regards
>> Conny
>> 
>> Kilian Weniger wrote:
>>> Hi all,
>>> 
>>> I think there is a possible race condition issue in RFC3775, which
>>> should be considered for RFC3775bis.
>>> 
>>> The scenario is as follows: A MN returns home and sends a BU
>>> de-registration. Once the HA receives the de-registration,
>> it deletes
>>> the BCE for the MN according to RFC3775. Now assume that just before
>>> returning home, the MN has sent a BU (either refresh BU or
>> BU with new
>>> CoA due to handover) and that the BU is delayed and is
>> received by the
>>> HA after the BU de-registration.
>>> 
>>> Since the HA has just deleted the MN's BCE due to the received BU
>>> de-registration, the HA would accept the delayed BU without
>> SN check and
>>> create a new BCE with a CoA pertaining to the previous
>> location of the
>>> MN. This results in wrong forwarding state in the HA and
>> hence packet
>>> loss for the MN till the MN sends a new BU (next handover
>> of the MN or
>>> the lifetime of the BCE expires).
>>> 
>>> A simple mitigation for this problem could be that the HA
>> keeps some BCE
>>> information (at least HoA and SN) for some time after receiving a BU
>>> de-registration. This would enable the HA to identify a
>> delayed BU as a
>>> delayed one based on the SN.
>>> 
>>> Comments?
>>> 
>>> BR,
>>> 
>>> Kilian
>>> 
>>> --------------------------------------------
>>> Dr. Kilian Weniger
>>> Panasonic R&D Center Germany
>>> Monzastr. 4c, 63225 Langen, Germany
>>> phone:  +49 (0)6103 766 137
>>> fax:    +49 (0)6103 766 166
>>> e-mail: kilian.weniger at eu.panasonic.com
>>> --------------------------------------------
>>> 
>>> 
>>> Panasonic R&D Center Germany GmbH
>>> 63225 Langen, Hessen, Germany
>>> Reg: AG Offenbach (Hessen) HRB 33974
>>> Managing Director: Thomas Micke
>>> 
>>> 
>>> _______________________________________________
>>> MEXT mailing list
>>> MEXT at ietf.org
>>> https://www.ietf.org/mailman/listinfo/mext
>>>   
>> 
>> 
>> 
> 
> 
> Panasonic R&D Center Germany GmbH
> 63225 Langen, Hessen, Germany
> Reg: AG Offenbach (Hessen) HRB 33974
> Managing Director: Thomas Micke
> 
> 
> _______________________________________________
> MEXT mailing list
> MEXT at ietf.org
> https://www.ietf.org/mailman/listinfo/mext


_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext