[strongSwan] Reg: 16 unknown bytes in ESp packet(IPSEC)

[Andreas Steffen]

Hi Mukesh,

please be aware that AES in Cipher Block Chaining (CBC) mode inserts
into each ESP packet a 16 byte (128 bit) Initialization Vector (IV)
right after the sequence number and in front of the encrypted payload.

Regards

Andreas

On 26.04.2012 19:29, Mukesh Yadav wrote:
> Hi,
> 
> Not able to understand 16 byetes in ESP packet present after sequence
> no and before Original IP header while doing tunnel mode Ipsec with
> ESP.
> Details are as below.
> 
> I am trying to achieve Ipsec functionality using fast-path application
> which will do encryption/decryption using some hardware(Cavium)
> specific API.
> This application will by-pass the IP layer of kernel..
> Keys for start-up are pre-shared.
> 
> Communication is done between two machine A and B.
> On Machine A running i386 linux, SA/SP database are updated using
> setkey utility and packets is encrypted/decrypted using kernel Ipsec.
> On Machine B Cavium h/w, keys are pre-shared to application performing
> Ipsec functionlity...
> 
> Example:
> M/c A configuration:
> add 50.50.50.51 50.50.50.53 esp 15701 -E aes-cbc "0123456789abcdef";
> spdadd 10.10.10.20 10.10.10.21 any -P out ipsec
>            esp/tunnel/50.50.50.51 50.50.50.53/require
> 
> 
> I am able to decrypt received packets on machine B send by M/c A and
> send encrypted packet to M/c A.
> Issue:
> 1. Not able to find what are 16 bytes present after sequence no in ESP
> header and before original IP header representing...
> 
> Decrypted  Packet on machine B is like below
> Ethernet header  14 bytes
> Outer Ip header   20 bytes
> ESP header    SPI 4 bytes      Seq no 4 bytes
> Some data         16 bytes       ???????
> Original IP header  20 bytes
> UDP header
> Payload data
> Padding
> Pad lenght
> Next Ip header
> 
> 2. Packets send from machine B are encrypted and received as ESP
> packet on machine A..
>     Not sure if decryption is happening fine...Seems packets are
> dropped at IP layer.. Is there way to confirm if packet are decrypted
> fine by kernel IPSEC...
>     Encrypted packet send by Machine B is having encrypted payload(of
> original IP header plus data) after Sequence number of ESP header...
>     Seems 16 bytes mentioned above play role for successful decryption
> at machine A running Linux IPSEC
> Any Inputs for same will be appreciated for same
> 
> Cheers
> Mukesh

======================================================================
Andreas Steffen                         andreas.steffen at strongswan.org
strongSwan - the Linux VPN Solution!                www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4489 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20120426/35b3451c/attachment.bin>