Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting

Xiangyang zhang <xiangyang.zhang@huawei.com> Fri, 20 May 2011 20:26 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 CF082E0742 for <ipsec@ietfa.amsl.com>; Fri, 20 May 2011 13:26:43 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 euM7fCCJiy3N for <ipsec@ietfa.amsl.com>; Fri, 20 May 2011 13:26:43 -0700 (PDT)
Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 22490E0710 for <ipsec@ietf.org>; Fri, 20 May 2011 13:26:43 -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 <0LLI00I26GSHSR@usaga04-in.huawei.com> for ipsec@ietf.org; Fri, 20 May 2011 15:26:42 -0500 (CDT)
Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLI00203GSG2D@usaga04-in.huawei.com> for ipsec@ietf.org; Fri, 20 May 2011 15:26:41 -0500 (CDT)
Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 20 May 2011 13:26:33 -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 13:26:38 -0700
Date: Fri, 20 May 2011 20:26:37 +0000
From: Xiangyang zhang <xiangyang.zhang@huawei.com>
In-reply-to: <4DD51EC2.2030709@gmail.com>
X-Originating-IP: [10.193.34.108]
To: Yaron Sheffer <yaronf.ietf@gmail.com>, Tero Kivinen <kivinen@iki.fi>
Message-id: <00E6CDB229A4CF4487D6E0326EDE5A030C3A09FA@dfweml502-mbx.china.huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_8mgek0TasQyJtYAwog/o1Q)"
Content-language: en-US
Accept-Language: en-US
Thread-topic: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting
Thread-index: AQHMFbOcHfxoosMvWkSdG/frQ+fnkZSUmnYAgAAFQQCAAXqVAA==
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> <4DD51EC2.2030709@gmail.com>
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 20:26:43 -0000

I agree.   Actually our intention is to provide informational RFC.  We do not change the sliding
window protocol for integrity service.  It just provide one alternative, or better alternative
in most cases, to the one specified in IPsec RFCs.

Thanks,

Xiangyang

From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
Sent: Thursday, May 19, 2011 6:45 AM
To: Tero Kivinen
Cc: Xiangyang zhang; ipsec@ietf.org; Tina Tsou
Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting

I mostly agree with Tero. But I think this would make for a nice independently-submitted, informational RFC.

Thanks,
    Yaron

On 05/19/2011 04:25 PM, Tero Kivinen wrote:

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



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.