RE: replay field size

Roy Pereira <rpereira@timestep.com> Mon, 10 February 1997 03:22 UTC

Received: from cnri by ietf.org id aa03287; 9 Feb 97 22:22 EST
Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa03466; 9 Feb 97 22:22 EST
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA03674 for ipsec-outgoing; Sun, 9 Feb 1997 15:36:57 -0500 (EST)
Message-ID: <c=US%a=_%p=TimeStep_Corpora%l=TSNTSRV2-970209204207Z-1699@tsntsrv2.timestep.com>
From: Roy Pereira <rpereira@timestep.com>
To: "'ipsec@tis.com'" <ipsec@tis.com>, 'Derrell Piper' <piper@tgv.com>
Subject: RE: replay field size
Date: Sun, 09 Feb 1997 15:42:07 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

ESP ad AH _should_ be very similar and thus utilize the same features. 
 Having one use a 32-bit replay counter and the other use a 64-bit one 
is silly as Derrell stated.  If 64-bit alignment is required, as in 
IPv6, then padding should be appended to the end of the header if it 
is needed due to the size of the digest algorithm used.

Why was RFC2085 (HMAC-MD5 IP Authentication with Replay Prevention) 
released with a 64-bit replay counter if so many of us objected?

Furthermore, why wasn't a generic digest algorithm RFC released 
(HMAC-x Authentication) instead?  We must standardize the common 
elements of our IPSEC protocols.  Things like Replay Counter, HMAC, 
Digest Algorithms, Cipher Algorithms, generation of Keys from keying 
material.  All of these common elements should be the same for all 
'transforms' and not have to be re-defined/re-invented in every 
transform RFC.  Can you imagine every cipher algorithm defining a 
different way to generate its keys and IV from the keying material?

We should be able to just plug in a new cipher algorithm and a new 
digest algorithm without having to re-invent the wheel.  Just plug in 
their identifiers and go...The common RFCs (ESP, AH, IPSEC-DOI) should 
define how to this without having to write a new transform RFC.  This 
way we do not need to create a new transform RFC for every combination 
of parameters.  For example, 3DES-Replay-HMAC-SHA1-LZS, has five 
parameters; cipher algorithm, replay, keyed function, digest 
algorithm, and compression algorithm.  With five parameters we can 
have quite a lot of transform RFCs.

    Cipher Algorithm:       None, DES, 3DES, RC5, Blowfish, IDEA
    Replay Protection:      No Replay, Replay
    Keyed Function:         None, Keyed, HMAC
    Digest Algorithm:       None, MD5, SHA1, Tiger
    Compression Algorithm:  None, LZS, GZIP

    6 * 2 * 3 * 4 * 3 = 432 different transform RFC combinations!!!


----------
From:  Derrell Piper[SMTP:piper@tgv.com]
Sent:  Saturday, February 08, 1997 7:45 PM
To:  ipsec@tis.com
Subject:  replay field size

There was clear consensus at the ANX IPSEC bakeoff last week to make 
the
size of the replay field 32-bits for both AH and ESP.  If we _must_ 
have
alignment for IPv4 IPSEC then the additional bits should be specified 
as
alignment.  No one wants to do 64-bit math for replay computation. 
 It's
silly.  In my opinion, IPv4 is misaligned for 64-bit hardware anyway 
and I
don't see the point of aligning the fields just to keep the protocol
consistent with IPv6.

I don't think this issue needs the Security AD to resolve.  I think 
we
already have consensus.  Let's hear now from anyone who absolutely 
must
have 64 bits or else move to revise AH and ESP to reflect consensus. 
 We
have much more interesting things to argue about.

Derrell