<div dir="ltr">Thanks a lot for the quick reply Andreas. <div><br></div><div>Rgds,</div><div>Lakshmi</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 21, 2016 at 6:35 PM, Andreas Steffen <span dir="ltr"><<a href="mailto:andreas.steffen@strongswan.org" target="_blank">andreas.steffen@strongswan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Lakshmi,<br>
<br>
no, IKEv1 does not support SHA2_256_96 for ESP. Since the corresponding<br>
ESP integrity algorithm is in the private identifier range and a<br>
strongSwan Vendor ID is required, you have to use strongSwan on both<br>
IPsec endpoints anyway. Therefore you can always set up the connection<br>
using IKEv2 so that there is no need for the legacy IKEv1 protocol.<br>
<br>
If you want to use 96 bit truncation with third party endpoints then the<br>
recommendation is to hack the kernel-netlink interface plugin so that<br>
when ESP SHA2_256 is proposed, strongSwan will use 96 bit instead of<br>
the correct 128 bit truncation. Have a look at the following issue that<br>
was posted a couple of months ago:<br>
<br>
<a href="https://wiki.strongswan.org/issues/1353" rel="noreferrer" target="_blank">https://wiki.strongswan.org/<wbr>issues/1353</a><br>
<br>
Regards<br>
<br>
Andreas<br>
<span class=""><br>
On 21.09.2016 14:16, Lakshmi Prasanna wrote:<br>
> Hi Andreas,<br>
><br>
> Does IKEv1 support SHA_256_96 for ESP ? I see that strongswan does not<br>
> send out the integrity algorithm when configured as SHA-256_96 for<br>
> IKEv1. However it works for IKEv2.<br>
><br>
> Thanks,<br>
> Lakshmi<br>
><br>
><br>
> On Fri, Aug 12, 2016 at 9:26 AM, Andreas Steffen<br>
</span>> <<a href="mailto:andreas.steffen@strongswan.org">andreas.steffen@strongswan.<wbr>org</a> <mailto:<a href="mailto:andreas.steffen@strongswan.org">andreas.steffen@<wbr>strongswan.org</a>>><br>
<div><div class="h5">> wrote:<br>
><br>
> Hi Lakshmi,<br>
><br>
> SHA-256 was implemented incorrectly for ESP with a 96 bit instead<br>
> of the standard 128 bit truncation in Linux kernels older than<br>
> 2.6.33.<br>
><br>
> Workarounds:<br>
><br>
> 1) Update to a kernel >= 2.6.33 (2.6.21 is ancient!)<br>
><br>
> 2) If you run strongSwan on both VPN end points you can select the<br>
> incorrect non-standard 96 bit truncation size by configuring<br>
><br>
> esp=aes128-sha256_96<br>
><br>
> In order for this non-standard algorithm ID to be accepted it might<br>
> also be necessary to activate the sending of the strongSwan vendor id<br>
> by setting<br>
><br>
> charon {<br>
> send_vendor_id = yes<br>
> }<br>
><br>
> in /etc/strongswan.conf<br>
><br>
> Regards<br>
><br>
> Andreas<br>
><br>
><br>
> On 12.08.2016 03:04, Lakshmi Prasanna wrote:<br>
><br>
> Experts,<br>
><br>
> Need urgent help.<br>
><br>
> When I try to use strongswan with SHA256, I see that the negotiation<br>
> fails at child SA creation time. I am using<br>
> strongSwan 5.1.3, Linux 2.6.21 version). Following is the log:<br>
><br>
> arsed CREATE_CHILD_SA response 4 [ N(USE_TRANSP) SA No TSi TSr ]<br>
><br>
> received netlink error: Invalid argument (22)<br>
><br>
> unable to add SAD entry with SPI c28f19c1<br>
><br>
> received netlink error: Invalid argument (22)<br>
><br>
> unable to add SAD entry with SPI c088894f<br>
><br>
> unable to install inbound and outbound IPsec SA (SAD) in kernel<br>
><br>
> failed to establish CHILD_SA, keeping IKE_SA<br>
><br>
> sending DELETE for ESP CHILD_SA with SPI c28f19c1<br>
><br>
><br>
> I have already tried the changes mentioned in<br>
> <a href="https://lists.strongswan.org/pipermail/users/2013-September/005203.html" rel="noreferrer" target="_blank">https://lists.strongswan.org/<wbr>pipermail/users/2013-<wbr>September/005203.html</a><br>
> <<a href="https://lists.strongswan.org/pipermail/users/2013-September/005203.html" rel="noreferrer" target="_blank">https://lists.strongswan.org/<wbr>pipermail/users/2013-<wbr>September/005203.html</a>><br>
> and it doesnt seem to work.<br>
><br>
> Is there any other fix for this issue?<br>
><br>
> Rgds,<br>
><br>
> Lakshmi<br>
><br>
> ==============================<wbr>==============================<wbr>==========<br>
> Andreas Steffen<br>
</div></div>> <a href="mailto:andreas.steffen@strongswan.org">andreas.steffen@strongswan.org</a> <mailto:<a href="mailto:andreas.steffen@strongswan.org">andreas.steffen@<wbr>strongswan.org</a>><br>
<span class="">> strongSwan - the Open Source VPN Solution!<br>
</span>> <a href="http://www.strongswan.org" rel="noreferrer" target="_blank">www.strongswan.org</a> <<a href="http://www.strongswan.org" rel="noreferrer" target="_blank">http://www.strongswan.org</a>><br>
<span class="">> Institute for Internet Technologies and Applications<br>
> University of Applied Sciences Rapperswil<br>
> CH-8640 Rapperswil (Switzerland)<br>
> ==============================<wbr>=============================[<wbr>ITA-HSR]==<br>
><br>
><br>
<br>
</span>--<br>
<div class="HOEnZb"><div class="h5">==============================<wbr>==============================<wbr>==========<br>
Andreas Steffen <a href="mailto:andreas.steffen@strongswan.org">andreas.steffen@strongswan.org</a><br>
strongSwan - the Open Source VPN Solution! <a href="http://www.strongswan.org" rel="noreferrer" target="_blank">www.strongswan.org</a><br>
Institute for Internet Technologies and Applications<br>
University of Applied Sciences Rapperswil<br>
CH-8640 Rapperswil (Switzerland)<br>
==============================<wbr>=============================[<wbr>ITA-HSR]==<br>
<br>
</div></div></blockquote></div><br></div>