[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] New RFC3775bis issue "BU de-registration race condition"?
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: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 euorg/mailman/listinfo/mext>,
<mailto:mext-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mext-bounces at ietf.org
Errors-To: mext-bounces at ietf.org
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: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.panason.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
ic.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