Re: length of IV in ESP_NULL cipher

["Tarun Ahuja" <tarun.ahuja@cavium.com>]

The padding is at the end of the packet (before authentication data)
but the IV after the ESP header and I am definitely seeing 4 extra
bytes after the ESP header.

Actually FreeSWAN doesnot have inbuilt support for NULL cipher
but there is an unofficial patch available for adding NULL cipher support.
I believe, the patch developers are aware of the problem because,
in the beta for the next release, the IV length has been changed to
0 but the version I am using, the IV length is 4 for NULL cipher. Looks like
the developer used IV length to be equal to the number of padding bytes.
As for Xedia talking to freeswan, I don't know, if you are talking about
communication using NULL cipher because, because the problem seems
related only to NULL cipher while other ciphers (3DES, AES at least) seem
to work fine.

Tarun

----- Original Message ----- 
From: "Paul Koning" <pkoning@equallogic.com>
To: <tarun.ahuja@cavium.com>
Cc: <ipsec@lists.tislabs.com>
Sent: Friday, January 09, 2004 7:09 AM
Subject: Re: length of IV in ESP_NULL cipher


> >>>>> "Scott" == Scott Fluhrer <sfluhrer@cisco.com> writes:
>
>  Scott> On Thu, 8 Jan 2004, Tarun Ahuja wrote:
>
>  >> Which essentially means the length of the IV should be 0 but
>  >> FreeSWAN uses a length of 4bytes IV (equal to blocksize) for NULL
>  >> cipher.
>
>  Scott> Well, either FreeSWAN is broke (at least in this respect) or
>  Scott> you are mistaken about the operation of the FreeSWAN code.
>
> Agreed.  I'm pretty sure I had our (Xedia) implementation talking to
> FreeSWAN some years ago, so my suspicion is that the implementation is
> actually correct.
>
> Are you looking at the packet length when you made this observation?
> Remember that ESP_NULL DOES require padding (to multiples of four)
> because that's the minimum requirement in ESP independent of cipher.
> I think I have seen implementations (at least back in 1999 or so) that
> got this wrong.
>
>     paul
>