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

Tero Kivinen <kivinen@iki.fi> Thu, 19 May 2011 13:26 UTC

Return-Path: <kivinen@iki.fi>
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 50DFFE07B3 for <ipsec@ietfa.amsl.com>; Thu, 19 May 2011 06:26:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 MYuhUKeL6EoN for <ipsec@ietfa.amsl.com>; Thu, 19 May 2011 06:26:40 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCC2E066A for <ipsec@ietf.org>; Thu, 19 May 2011 06:26:39 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p4JDPnsm028091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 May 2011 16:25:49 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p4JDPk4j020692; Thu, 19 May 2011 16:25:46 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <19925.6746.823649.293241@fireball.kivinen.iki.fi>
Date: Thu, 19 May 2011 16:25:46 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Xiangyang zhang <xiangyang.zhang@huawei.com>
In-Reply-To: <00E6CDB229A4CF4487D6E0326EDE5A030C3A073B@dfweml502-mbx.china.huawei.com>
References: <20110506091501.19592.66261.idtracker@ietfa.amsl.com> <00E6CDB229A4CF4487D6E0326EDE5A030C3A073B@dfweml502-mbx.china.huawei.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 8 min
X-Total-Time: 8 min
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: Thu, 19 May 2011 13:26:41 -0000

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. 
-- 
kivinen@iki.fi