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

Xiangyang zhang <xiangyang.zhang@huawei.com> Wed, 18 May 2011 23:30 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 300CDE06DF for <ipsec@ietfa.amsl.com>; Wed, 18 May 2011 16:30:54 -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 WdvpBQAfC8k5 for <ipsec@ietfa.amsl.com>; Wed, 18 May 2011 16:30:53 -0700 (PDT)
Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3C916E0651 for <ipsec@ietf.org>; Wed, 18 May 2011 16:30:53 -0700 (PDT)
Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLE00C4CZZEJE@usaga02-in.huawei.com> for ipsec@ietf.org; Wed, 18 May 2011 16:30:51 -0700 (PDT)
Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LLE00HZOZZE4H@usaga02-in.huawei.com> for ipsec@ietf.org; Wed, 18 May 2011 16:30:50 -0700 (PDT)
Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 18 May 2011 16:30:51 -0700
Received: from DFWEML502-MBX.china.huawei.com ([fe80::1086:4a1f:19fa:9025]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 18 May 2011 16:30:46 -0700
Date: Wed, 18 May 2011 23:30:45 +0000
From: Xiangyang zhang <xiangyang.zhang@huawei.com>
In-reply-to: <20110506091501.19592.66261.idtracker@ietfa.amsl.com>
X-Originating-IP: [10.193.34.108]
To: Tina Tsou <tena@huawei.com>, "ipsec@ietf.org" <ipsec@ietf.org>
Message-id: <00E6CDB229A4CF4487D6E0326EDE5A030C3A073B@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: Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting
Thread-index: AQHMFbOcHfxoosMvWkSdG/frQ+fnkQ==
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
References: <20110506091501.19592.66261.idtracker@ietfa.amsl.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: Wed, 18 May 2011 23:30:54 -0000

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.  


-----Original Message-----
From: Tina Tsou [mailto:tena@huawei.com]
Sent: Tuesday, May 10, 2011 12:46 PM
To: 'ipsec@ietf.org'
Cc: 'Xiangyang zhang'
Subject: Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting

Hi,
Victor and I just submitted
https://datatracker.ietf.org/doc/draft-zhang-ipsecme-anti-replay/

IPsec anti-replay algorithm without bit-shifting

This document presents a new method to do anti-replay check and 
   update, which becomes one alternative to the anti-replay 
   algorithm in RFC 4302 and RFC4303.  The new method will deem the 
   bit-shifting unnecessary.  It will reduce the number of times 
   to slide the window.  In addition, it makes bit-check and 
   bit-update easier as it does not depend on the low index of the 
   sliding window.  It is especially beneficial when the window size 
   is much bigger than 64 bits, for example, 1024 bits.

   IPsec employs one anti-replay sliding window protocol to secure 
   against an adversary that can insert the messages inside the 
   network tunnel.  This method still inherits the sliding window 
   protocol, but use one or more redundant bytes to ease the update 
   of sliding window.  The bit-shifting is deemed unnecessary with 
   updating the high and low index of the window, which is especially 
   efficient in case of the big window size.  Thus the method reduces
   the number of times to update the window.  

   In addition, the bit location is fixed for one sequence number, 
   thus makes the bit check easier and faster.

Comments are more than welcome.


We keep our promises with one another - no matter what!

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html