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

Mukesh Yadav write2mukesh84 at gmail.com
Thu Apr 26 20:27:14 CEST 2012

Thanks Andreas,
That means when I create a encrypted packet using some application, at
other for successful decryption by Ipsec Kernel, 16 bytes IV need to
be inserted after sequence number.....


On 26 April 2012 23:14, Andreas Steffen <andreas.steffen at strongswan.org> wrote:
> 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 esp 15701 -E aes-cbc "0123456789abcdef";
>> spdadd any -P out ipsec
>>            esp/tunnel/
>> 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]==

More information about the Users mailing list