Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting
Xiangyang zhang <xiangyang.zhang@huawei.com> Fri, 20 May 2011 19:18 UTC
Return-Path: <xiangyang.zhang@huawei.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEF1E07B4 for <ipsec@ietfa.amsl.com>; Fri, 20 May 2011 12:18:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXISfNDWk-BR for <ipsec@ietfa.amsl.com>; Fri, 20 May 2011 12:18:05 -0700 (PDT)
Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 734C7E06A6 for <ipsec@ietf.org>; Fri, 20 May 2011 12:18:05 -0700 (PDT)
Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLI008NADM4CW@usaga04-in.huawei.com> for ipsec@ietf.org; Fri, 20 May 2011 14:18:04 -0500 (CDT)
Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLI00269DM32D@usaga04-in.huawei.com> for ipsec@ietf.org; Fri, 20 May 2011 14:18:03 -0500 (CDT)
Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 20 May 2011 12:18:05 -0700
Received: from DFWEML502-MBX.china.huawei.com ([fe80::1086:4a1f:19fa:9025]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Fri, 20 May 2011 12:17:59 -0700
Date: Fri, 20 May 2011 19:17:58 +0000
From: Xiangyang zhang <xiangyang.zhang@huawei.com>
In-reply-to: <19925.6746.823649.293241@fireball.kivinen.iki.fi>
X-Originating-IP: [10.193.34.108]
To: Tero Kivinen <kivinen@iki.fi>
Message-id: <00E6CDB229A4CF4487D6E0326EDE5A030C3A09E0@dfweml502-mbx.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-language: en-US
Content-transfer-encoding: 7bit
Accept-Language: en-US
Thread-topic: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting
Thread-index: AQHMFbOcHfxoosMvWkSdG/frQ+fnkZSUmnYAgAF8T7A=
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
References: <20110506091501.19592.66261.idtracker@ietfa.amsl.com> <00E6CDB229A4CF4487D6E0326EDE5A030C3A073B@dfweml502-mbx.china.huawei.com> <19925.6746.823649.293241@fireball.kivinen.iki.fi>
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, Tina Tsou <tena@huawei.com>
Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 May 2011 19:18:06 -0000
-----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Thursday, May 19, 2011 6:26 AM To: Xiangyang zhang Cc: Tina Tsou; ipsec@ietf.org Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting Xiangyang zhang writes: > This proposal addresses two major issues in IPsec anti-replay service: > 1. Some high end security router can configure thousands of bits for > anti-replay window. For example, Juniper can configure up to 4096 > bits. The bit-shifting for this window is a tremendous burden, > resulting in the performance drop. > 2. High-end network processor could have multiple crypto cores to > access the window. In order to check and update the window, the > exclusive lock must be obtained. If I have understood correctly the algorith listed in the rfc4302 etc is only for illustrative pseudo-code, the actual implementations may be different (and at least our implementation do not use bit-shifting at all as it would be way too inefficient). [xiangyang] Three RFCs describe almost the same algorithm. For illustrative pseudo-code, it shifts bits when the window is updated (Page 41 in RFC4303). Definitely it is efficient if bit-shifting is bypassed. In addition, the check and set of the specific bit is also simplified here. In old method, the location of the bit depends on both the largest sequence number received and the current sequence number. Instead, it only depends on the sequence number currently received. The anti-replay checking in the IPsec is local matter to the implementation and does not have any interoperability requirements in addition that the sequence number field is always present. This draft provides nice alternative algorithm to the one provided in the RFC, but as the algorithm listed in the current rfc is not mandated anyways and there is no externally visible differences in the algorithms I do not see reason to document this as RFC. This would be better as techinal paper about providing faster algorithm for the anti-replay checking. -- kivinen@iki.fi
- Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPse… Yaron Sheffer
- [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-pro… Internet-Drafts
- Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPse… Xiangyang zhang
- Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPse… Tero Kivinen
- Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPse… Xiangyang zhang
- Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPse… Xiangyang zhang
- Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPse… Tina Tsou