Re: [IPsec] IV in ESP packets for AES-CBC and AES-CTR methods

[ss murthy nittala <[e-mail]>]

The following sentence present in RFC 3602 creates some doubts 
whether IV in each packet is mandatory or not?

"Including the IV in each datagram ensures that decryption of each
  received datagram can be performed, even when some datagrams are
  dropped, or datagrams are re-ordered in transit."

Thanks
-ns murthy

At 08:00 PM 5/11/2009, Tero Kivinen wrote:
>ss murthy nittala writes:
> > Is it required for IV to be randomly generated for each ESP packet in
> > case of AES-CTR and AES-CBC methods?
> >
> > AES-CTR:My understanding is that IV is to be generated randomly for
> > the first packet.For each new outgoing packet increment IV and use it.
>
> From RFC3686:
>
>    The AES-CTR IV field MUST be eight octets.  The IV MUST be chosen by
>    the encryptor in a manner that ensures that the same IV value is used
>    only once for a given key.  The encryptor can generate the IV in any
>    manner that ensures uniqueness.  Common approaches to IV generation
>    include incrementing a counter for each packet and linear feedback
>    shift registers (LFSRs).
>
>I.e. it MUST be unique, but there is no other requirements for it.
>Incremental counter is one commonly used method.
>
> > AES-CBC:Is it required for IV to be randomly generated for each of
> > the outgoing ESP packets?In any case i think the packet shall include IV.
>
> From RFC3602:
>
>    The IV field MUST be the same size as the block size of the cipher
>    algorithm being used.  The IV MUST be chosen at random, and MUST be
>    unpredictable.
>...
>    To avoid CBC encryption of very similar plaintext blocks in different
>    packets, implementations MUST NOT use a counter or other low-Hamming
>    distance source for IVs.
>
>I.e. it MUST be unpredictable, i.e. randomly generated is good. Using
>the final ciphertext block of the previous message is NOT acceptable.
>--
>[e-mail]