Re: [RFC/RFT] projects/ipsec

From: Alexandr Krivulya <shuriku_at_shurik.kiev.ua>
Date: Fri, 13 Jan 2017 17:23:26 +0200
11.12.2016 01:07, Andrey V. Elsukov пишет:
> Hi All,
>
> I am pleased to announce that projects/ipsec, that I started several
> months ago is ready for testing and review.
> The main goals were:
>    * rework locking to make IPsec code more friendly for concurrent
>      processing;
>    * make lookup in SADB/SPDB faster;
>    * revise PFKEY implementation, remove stale code, make it closer
>      to RFC;
>    * implement IPsec VTI (virtual tunneling interface);
>    * make IPsec code loadable as kernel module.
>
> Currently all, except the last one is mostly done. So, I decided ask for
> a help to test the what already done, while I will work on the last task.
>
> How to try? There are no patches, you need to checkout the full
> projects/ipsec source tree, and build the kernel and the base system.
> There are very few changes in the base system, mostly the kernel
> changes. Thus for testing that old configuration is still work, it is
> enough to build only the kernel.
>
> The approximate list of changes that may be visible to users:
> * SA bundles now can have only 4 items in the chain. I think it is
> enough, I can't imagine configurations when needed more. Also now SA
> bundles supported for IPv6 too.
> * due to changes in SPDB/SADB, systems where large number of SPs and SAs
> are in use should get significant performance benefits.
> * the memory consumption should slightly increase. There are several
> hash tables and SP cache appeared.
> * INPCB SP cache should noticeable increase network performance of
> application when security policies are presence.
>    https://lists.freebsd.org/pipermail/freebsd-net/2015-April/042121.html
> * use transport mode IPsec for forwarded IPv4 packets now unsupported.
> This matches the IPv6 behavior, and since we can handle the replies, I
> think it is useless.
> * Added net.inet.ipsec.check_policy_history sysctl variable. When it is
> set, each inbound packet that was handled by IPsec will be checked
> according to matching security policy. If not all IPsec transforms were
> applied, the check will fail, and packet will be dropped.
> * Many PF_KEY messages handlers was updated, probably some IKEd now may
> fail due to stricter checks.
> * SPI now unique for each SA. This also can break something.
> * Added if_ipsec interface. For more info look at
>    https://svnweb.freebsd.org/base?view=revision&revision=309115
>    https://reviews.freebsd.org/P112
> * TCP_SIGNATURE code was reworked and now it behaves closer to RFC
>    https://svnweb.freebsd.org/base?view=revision&revision=309610
> * NAT-T support was reworked.
>    https://svnweb.freebsd.org/base?view=revision&revision=309808
> Also I made the patch to racoon that adds better support of NAT-T,
> you can use this port to build patched racoon:
>    https://people.freebsd.org/~ae/ipsec-tools.tgz
>
> What results is interesting to me?
> If you have some nontrivial configuration, please test.
> If you have some configuration, that did't work, please test this branch.
> If you have performance problems, please test. But don't forget that
> this is head/ branch, you need to disable all debugging first.
> If you just want to test, pay attention to the output of
> `vmstat -m | egrep "sec|sah|pol|crypt"`.
> If you have used TCP_SIGNATURE, IPSEC_NAT_T options, please test, this
> support was significantly changed.
>
> PS. I just updated the branch to last head/, and it was not tested, sorry :)
>

Hi, nothing unusual, all works fine. Strangswan in tunnel mode on current:

root_at_thinkpad:/home/shurik # ipsec status
Security Associations (1 up, 0 connecting):
ikev2-client[1]: ESTABLISHED 3 minutes ago, 
10.1.1.183[xxx.xxxx.org.ua]...xxx.yyy.74.7[xxx.xxxx.org.ua]
ikev2-client{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: 
c6f68157_i c6d17c85_o
ikev2-client{1}:   10.10.10.2/32 === 0.0.0.0/0

-- 
Received on Fri Jan 13 2017 - 14:23:42 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:09 UTC