Re: replay field size

Derrell Piper <piper@tgv.com> Wed, 12 February 1997 22:23 UTC

Received: from cnri by ietf.org id aa24419; 12 Feb 97 17:23 EST
Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa16294; 12 Feb 97 17:23 EST
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA00233 for ipsec-outgoing; Wed, 12 Feb 1997 17:14:06 -0500 (EST)
Message-Id: <199702122218.OAA07059@fluffy.cisco.com>
To: ipsec@tis.com
Subject: Re: replay field size
In-reply-to: Your message of "Tue, 11 Feb 1997 03:53:56 EST." <Chameleon.855637101.rja@c8-a.snvl1.sfba.home.com>
Date: Wed, 12 Feb 1997 14:18:07 -0800
From: Derrell Piper <piper@tgv.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

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

Yes.

I just don't see the need for a replay field that spans 4GB of packets.  We
can always add a negotiated option within the IPSEC DOI, should we decide
that the need is there for much stronger encryption algorithms.  That's the
nice thing about having a negotiated key management protocol.  However I do
not believe that replay warrants a negotiated option.  Any option, no
matter how small, increases the risk of non-interoperability.
ISAKMP/Oakley and IPSEC are complicated enough as it is.

>If they have a fixed size counter, what size should it be? (32 bits/64 bits)

32-bits.  

Add a separate padding field if you want 64-bit alignment in IPv4.  You
have to ask yourself though what effect aligning just these particular
headers is going to have on overall processing of IPv4 IP...  I think it's
lost in the noise.

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

A much harder question.  Like many, I tend to want to accept Hugo's
recommendation, but I'm not qualified to judge.  Obviously this question
should be decided on the merit of the strength of the HMAC though, and not
on an alignment issue.  If we decide that 128-bits probably increases the
strength of the HMAC _and_ this happens to fix the alignment, great.  If
not, adding padding to fix the alignment is no big deal.  I personally
don't care about the size of the packet.

It seems we really don't have concensus on whether or not 64-bit alignment
is important for IPv4.  My belief is that IPv4 is not inherently 64-bit
aligned and forcing the IPSEC transforms to be 64-bit aligned will not fix
this.  I don't underestimate the importance of alignment for 64-bit RISC
processors; I worked in the VMS group at DEC when we were porting to Alpha.
However folks like Phil Karn have, in the past, been quite vocal about
keeping the number of bytes to a minimum and 32-bits _is_ the natural
alignment for the rest of IPv4.

I'd like to see us come to consensus on the 64-bit alignment issue now too.
What are other working groups doing with respect to IPv6/IPv4 alignment?

Derrell