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

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

Hi Kilian,

> Subject: RE: [MEXT] New RFC3775bis issue "BU de-registration 
> race condition"?
> 
> Hi Ahmad, 
> 
> > I see this a very very rare race condition that possibly may never 
> > happen.
> 
> I agree this is a very rare case, but the consequence can be 
> drastic (packet loss till next BU). 
> 
> Furthermore, I think this case is not less likely than the 
> case that registration Binding Updates overtake each other, 
> which is handled in
> RFC3775 by sequencing of Binding Updates with the Sequence 
> Number. Or do you say sequencing of Binding Updates is not 
> needed at all in RFC3775bis?

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


> 
> > 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
> 
> 
> 
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext