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

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 14 Oct 2008 10:59:16 +0200

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: [email-masked]
--------------------------------------------

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Conny Larsson <[email-masked]>
Date: Tue, 14 Oct 2008 12:18:28 +0200

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

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 14 Oct 2008 21:57:26 +1100

On 14/10/08 7:59 PM, "Kilian Weniger" <[email-masked]>
wrote:

> de-registration, the HA would accept the delayed BU without SN check

=> How can it accept it without an IPsec SA? If the SA is already there it
won't accept it. If the SA is no longer there then it won't accept it
either. 

Hesham

and

---

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 14 Oct 2008 14:06:50 +0200

Hi Conny, Hesham,

right, the delayed BU is not accepted by HA if the SAs for protecting
MIP6 signaling traffic are deleted once the MN is returning home (i.e.,
when BU de-registration is received by HA). 

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.  

BR,

Kilian

> -----Original Message-----
> From: Conny Larsson [mailto:[email-masked]] 
> Sent: Dienstag, 14. Oktober 2008 12:18
> To: Kilian Weniger
> Cc: [email-masked]
> Subject: Re: [MEXT] New RFC3775bis issue "BU de-registration 
> race condition"?
> 
> Hi Kilian,
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 14 Oct 2008 08:46:19 -0500

Hi Kilian,

I see this a very very rare race condition that possibly may never
happen.
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.

So I am wondering why we need to consider this case?

Regards,
Ahmad

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Kilian Weniger
> Sent: Tuesday, October 14, 2008 3:59 AM
> To: [email-masked]
> 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.
> 
> 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 
> 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
>

---

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 14 Oct 2008 16:49:10 +0200

Hi Ahmad, 

> I see this a very very rare race condition that possibly may never

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?

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

> So I am wondering why we need to consider this case?

see above for reasoning.

BR,

Kilian

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 14 Oct 2008 14:11:39 -0500

Hi Kilian,

> Subject: RE: [MEXT] New RFC3775bis issue "BU de-registration 
> race condition"?
> 
> Hi Ahmad, 
> 
> 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 
> 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.

> > > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > > Of Kilian Weniger
> > > 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. 
> > > 
> > > 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).
> > > 
> 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
> > > 
> > > Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: 
> Thomas Micke
> > > 
> > >

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 15 Oct 2008 10:18:29 +0200

Hi Hesham, 

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

But how can the HA know that the seqno in the received BU is old? In
this specific scenario the HA has deleted the MN's BCE containing the
current seqno before receiving the delayed BU (upon receiving the BU
de-registration).

Or do you refer to the IPsec ESP seqno? IPsec ESP wouldn't discard a BU
with old ESP seqno, since ESP doesn't provide correct ordering of
messages (just anti-replay service). 

BR,

Kilian

> >> keeps some BCE

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 15 Oct 2008 10:15:30 +0200

Hi Ahmad, 

> de-registration. If that happens, this race condition is nothing but a

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

> received BU

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 15 Oct 2008 16:11:38 +1100

> SAs protecting MIP6 signaling traffic should not be deleted when MN is

=> 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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 16 Oct 2008 17:21:44 -0500

Hi Kilian,

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

Regards,
Ahmad

> 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 

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

> 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]