[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
returFrom mext-bounces at ietf.org Tue Oct 14 03:18:18 2008
Return-Path: <mext-bounces at ietf.org>
X-Original-To: nemo-web-archive at megatron.ietf.org
Delivered-To: ietfarch-nemo-web-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 6777428C126;
Tue, 14 Oct 2008 03:18:18 -0700 (PDT)
X-Original-To: mext at core3.amsl.com
Delivered-To: mext at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 967F63A6BA6
for <mext at core3.amsl.com>; Tue, 14 Oct 2008 03:18:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Oy+gvRTN7vNp for <mext at core3.amsl.com>;
Tue, 14 Oct 2008 03:18:16 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60])
by core3.amsl.com (Postfix) with ESMTP id 343463A6BCC
for <mext at ietf.org>; Tue, 14 Oct 2008 03:18:15 -0700 (PDT)
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
0ADB120E73; Tue, 14 Oct 2008 12:18:37 +0200 (CEST)
X-AuditID: c1b4fb3c-af0d0bb0000015b5-65-48f471fc69ce
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
C62D1206AD; Tue, 14 Oct 2008 12:18:36 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by
esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
Tue, 14 Oct 2008 12:18:29 +0200
Received: from [127.0.0.1] ([147.214.130.70]) by esealmw126.eemea.ericsson.se
with Microsoft SMTPSVC(6.0.3790.1830);
Tue, 14 Oct 2008 12:18:29 +0200
Message-ID: <48F471F4.8030503 at ericsson.com>
Date: Tue, 14 Oct 2008 12:18:28 +0200
From: Conny Larsson <conny.larsson at ericsson.com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Kilian Weniger <Kilian.Weniger at eu.panasonic.com>
References: <1FEB9B9F2EC38343955D02B2AE86AACBCF7B9E at lan-ex-02.panasonic.de>
In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACBCF7B9E at lan-ex-02.panasonic.de>
X-OriginalArrivalTime: 14 Oct 2008 10:18:29.0242 (UTC)
FILETIME=[33D9F5A0:01C92DE6]
X-Brightmail-Tracker: AAAAAA==
Cc: mext at ietf.org
Subject: Re: [MEXT] New RFC3775bis issue "BU de-registration race condition"?
X-BeenThere: mext at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>,
<mailto:mext-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mext>
List-Post: <mailto:mext at ietf.org>
List-Help: <mailto:mext-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>,
<mailto:mext-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: mext-bounces at ietf.org
Errors-To: mext-bounces at ietf.org
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 beforening 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
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