RE: replay field size

Dan McDonald <Dan.McDonald@eng.sun.com> Tue, 11 February 1997 20:50 UTC

Received: from cnri by ietf.org id aa29967; 11 Feb 97 15:50 EST
Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa22683; 11 Feb 97 15:50 EST
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19797 for ipsec-outgoing; Tue, 11 Feb 1997 15:34:18 -0500 (EST)
From: Dan McDonald <Dan.McDonald@eng.sun.com>
Message-Id: <199702111926.LAA13021@kebe.eng.sun.com>
Subject: RE: replay field size
To: ipsec@tis.com
Date: Tue, 11 Feb 1997 11:26:45 -0800
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

> Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't
> Care)

No.

Listen folks, it ain't that hard to build.  Replay counter size is a function
of what is negotiated in the SA.  You have all the data right there.  Use the
information in the association and set your pointers accordingly.  The
annoyance of checking for variable-sized replay counters is lost in the noise
of a CPU-hungry HMAC calculation.  Even if you have hardware-assist on the
HMAC, the memory access time will at least be dominant, if not overwhelming.

Let's not forget IPv6 alignment requirements, too!  Though admittedly,
creative padding can fix this problem.

> Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't
> Care)

Yes, simply because I trust Hugo's opinion on this.

Dan