[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
;)
Furthermore, this behaviour is not specified in RFC3775. Even if it
would work, I guess it would need to be described in RFC3775bis.
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