[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(Fwd) Re: Question on IV for ESP payload
Forwarded message:
From: Self <FS1/RL>
To: owner-ipsec@lists.tislabs.com
Subject: Re: Question on IV for ESP payload
Reply-to: RL@incaa.nl
Date: Tue, 11 May 1999 20:30:21 +0200
On 10 May 99 at 8:50, Loretta Zhou <lzhou@netrover.com> wrote:
> Q1) Should we create the first IV using a random number or using
> the algorithm defined in appendix B of RFC2409? If we follow
> RFC2409, do we store IV (last phase 1 CBC output block) as part
> of the SA fields?
If you are implementing IKE, you should do it according the IKE spec
RFC2409. Appendix B tells how to generate initial IV for phase 1 and
2, and how to extend the IV to the blocksize.
If you are implementing IPsec IP ESP, see the ESP spec RFC2406.
The IV is random and carried in the payload data.
> Q2) RFC2406 (IP ESP) indicates that the IV size of 32 and 64 bits are
> required to be supported. It also states that "When the size is
> 32-bits, a 64-bit IV is formed from the 32-bit value followed by
> (concatenated with) the bit-wise complement of the 32-bit value".
>
> Since the IV is always going to be 64-bit, why do we have to support
> size 32 and 64? If we use the method defined in appendix B of
> RFC2409, we're always going to get a 64-bit block, how do we support
> size 32 anyway? What determines if we need to do size 32 or 64 IV
> for encryption (eg. user provisiong, default, ...)?
The blocksize of the cipher.
> Q3) What's the difference between transform ID 1/9 (ESP_DES_IV64/ESP_DES_IV32)
>
> and ID 2 (ESP_DES)? If the SA is negotiated to support ID 2, it still
> needs to have an IV64/IV32 for CBC operation later, is it not right?
I would say no; you only need what is negotiated.
> Regards,
> Li Zhou.
note: your message arrived here with a malformed mail-header.
Robert.
--
Robert Luursema R.Luursema@incaa.nl Incaa Datacom b.v.