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

["Ahmad Muhanna" <amuhanna at nortel.com>]

Hi Kilian,

Sorry for the late reply. Please see one comment inline.

Regards,
Ahmad

> Subject: RE: [MEXT] New RFC3775bis issue "BU de-registration 
> race condition"?
> 
> Hi Ahmad, 
> 
> > No I do not want any change for the way sequence number is handled; 
> > however, in this specific case, before the mobile node sends a 
> > de-registration BU, the mobile node knows for sure that there is an 
> > outstanding BU with a different CoA. IMO, the mobile node 
> SHOULD wait 
> > until it receives a BA or expires all retransmissions 
> before sending a 
> > de-registration. If that happens, this race condition is 
> nothing but a 
> > theoretical one.
> 
> I see what you mean, but I'm not sure if this actually works, 
> because in this specific scenario the MN has moved from the 
> foreign link to the home link after sending the BU and before 
> receiving the BA. The BA is sent to the source address of the 
> BU (i.e., to the foreign link) and hence cannot be received 
> by the MN (unless the MN is still attached to the foreign 
> link while being attached to the home link, which cannot be 
> assumed to be generally true). So the MN would wait forever 
> for the BA.

[Ahmad]
Well, it depends, but BA may not come back, however, I still believe
that the least the mobile node should do is to wait for retransmission
timer to expires before sending the de-registration BU. If that happens,
then I believe this race condition becomes somewhat theoretical.

> ;)
> 
> Furthermore, this behaviour is not specified in RFC3775. Even 
> if it would work, I guess it would need to be described in RFC3775bis.

[Ahmad]
Hmmm... I am not sure if we need to document this in the RFC3775bis,
because, IMO, this nothing but how the mobile node should handle its
state machine gracefully. 

> 
> BR,
> 
> Kilian
> 
> > 
> > 
> > > 
> > > > Both BU are sent by the mobile node and the mobile node,
> > before it
> > > > sent the de-registration BU, it is for sure aware that
> > there is an
> > > > outstanding BU that has not been acknowledged yet.
> > > 
> > > Even though the MN knows that the previous BU has not been 
> > > acknowledged yet, the MN does not know whether the BU has 
> overtaken 
> > > the BU de-reg or not, i.e., whether wrong forwarding state was 
> > > actually established in HA or not. For instance, it is 
> also possible 
> > > that just the BAck was delayed/lost.
> > 
> > [Ahmad]
> > The mobile node does not need to know any of that at all. 
> All what the 
> > mobile node needs to know is to make sure that the 
> outstanding BU is 
> > handled properly according to RFC3775 before sending a new 
> BU with a 
> > different CoA, which happened in this case to be a de-registration.
> > 
> > 
> > > 
> > > > So I am wondering why we need to consider this case?
> > > 
> > > see above for reasoning.
> > > 
> > > BR,
> > > 
> > > Kilian
> > > 
> > > > 
> > > > Regards,
> > > > Ahmad
> > > >  
> > > > 
> > > > > -----Original Message-----
> > > > > From: mext-bounces at ietf.org
> > > [mailto:mext-bounces at ietf.org] On Behalf
> > > > > Of Kilian Weniger
> > > > > Sent: Tuesday, October 14, 2008 3:59 AM
> > > > > To: mext at ietf.org
> > > > > Subject: [MEXT] New RFC3775bis issue "BU de-registration race 
> > > > > condition"?
> > > > > 
> > > > > 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
> > > > > 
> > > > _______________________________________________
> > > > 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
> > > 
> > > 
> > > 
> > 
> > 
> 
> 
> 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