Re: replay field size

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

Received: from cnri by ietf.org id aa12657; 10 Feb 97 21:13 EST
Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa28772; 10 Feb 97 21:13 EST
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA13472 for ipsec-outgoing; Mon, 10 Feb 1997 20:55:39 -0500 (EST)
From: Dan McDonald <Dan.McDonald@eng.sun.com>
Message-Id: <199702110156.RAA06362@kebe.eng.sun.com>
Subject: Re: replay field size
To: ipsec@tis.com
Date: Mon, 10 Feb 1997 17:56:28 -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

I came in on this one late, folks.  Apparently I was shoved on the TIS
"bounce" list.  P*sses me off when I miss things.  If I rehash anything here,
I apologize.

Anyway, w.r.t. replay counters, and what have you.  Please keep in mind a
couple of things:

	1.)  Rememember that when a replay counter wraps, you must rekey.
	     I dunno how fast 2^32 packets happens, but is that enough
	     for a given key lifetime?

	2.)  IPv6 options MUST, I repeat MUST be 8-byte aligned.  A 32-bit
	     SPI + a 32-bit replay + a 160-bit SHA output is NOT 32-bit
	     aligned.  OTOH if you change the replay to 64-bits, you're
	     64-bit aligned.

	3.)  I'm assuming replay counter size is a property of the Security
	     Association being used.  Since I have to parse the rest of the
	     AH based on SA information, why is the bit of code to handle
	     replay counters any different than the code handling the
	     authentication data, or whether there's replay protection in the
	     first place?

I'll admit replay protection isn't where my attention is currently, but I
just don't see it as that hard of a problem.  Just bang together the rocks
together, guys!

Dan