IETF Logo Mail Archive

Re: replay field size

Ran Atkinson <rja@inet.org> Fri, 14 February 1997 16:16 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA15161 for ipsec-outgoing; Fri, 14 Feb 1997 11:16:35 -0500 (EST)
Date: Fri, 14 Feb 1997 16:13:10 +0000
From: Ran Atkinson <rja@inet.org>
Subject: Re: replay field size
To: Ran Atkinson <rja@inner.net>, Steven Bellovin <smb@research.att.com>
Cc: ipsec@tis.com, Robert Glenn <glenn@snad.ncsl.nist.gov>, Stephen Kent <kent@bbn.com>
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <199702131637.LAA02391@raptor.research.att.com>
Message-ID: <Chameleon.855937008.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

Steve,

  For the case where the algorithm is DES, I have no problems with
your analysis.

  For the case where the algorithm is something new that appears in
future that might be significantly stronger, then the limit of 2^^32
might well be a significant issue.  With negotiable counter sizes or
per-algorithm counter sizes, this would not be an issue.  With a fixed
size counter, using 2^^32 for all time is an issue IMHO.  However,
a 2^^64 counter space would not have that issue and would still be
a fixed size counter.

  As to the 64-bit math, I'm not very concerned -- based on my work on
several different IPv6 implementations and the currently 128-bit
addresses (and the routing calculations that go along with that address
size).  This was NOT a problem on an Intel Pentium.

Ran
rja@inet.org

v2.28.0 | Report a Bug | By Email | System Status