Re: Replay counter sizes: AH vs ESP -Reply

[Roy Pereira <rpereira@TimeStep.com>]

But adding padding would not hurt processing of the AH payload greatly.
While having a replay field that may change in size due to the size of
the digest algorythm, increases both code and complexity of that code to
handle processing.

I'd like to see both replay fields in AH and ESP to be 32-bits and then
we may add extra padding to the end of these payloads to align them to
64-bits.

>----------
>From: 	Robert Glenn[SMTP:glenn@snad.ncsl.nist.gov]
>Sent: 	Friday, December 06, 1996 8:24 AM
>To: 	Andrew Robison; Roy Pereira
>
>IAA04917; Fri, 6 Dec 1996 08:23:37 -0500 (EST)
>Date: Fri, 6 Dec 1996 08:23:37 -0500 (EST)
>Message-Id: <199612061323.IAA04917@sloth.ncsl.nist.gov>
>To: ipsec@tis.com
>Subject: Re: Replay counter sizes: AH vs ESP -Reply
>Sender: owner-ipsec@portal.ex.tis.com
>Precedence: bulk
>
>Keep in mind that these transforms are specified to provide security services
>for both version 4 and 6 of IP.  IPv6 insists that "each extension header
>be an integer multiple of 8 octets, in order to retain 8-octet alignment for
>subsequent headers." (RFC1883)  The differences in the Replay Prevention
>fields
>is primarily due to this alignment.  A change to either would require
>adding an additional 32 bits of wasteful pad.
>
>Rob G.
>-- 
>rob.glenn@nist.gov
>
>
>
>
>

---

• Prev by Date: Re: ISAKMP DOI Question (General, Not IP Specific)
• Next by Date: Re: ISAKMP DOI Question (General, Not IP Specific)
• Prev by thread: Replay counter sizes: AH vs ESP -Reply
• Next by thread: Last Call: Combined DES-CBC, HMAC and Replay Prevention Security Transform to Proposed Standard
• Index(es):
  • Main
  • Thread