Bug 128030
| Summary: | [ipsec] Enable IPSec in GENERIC kernel configuration | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Lionel Fourquaux <lionel.fourquaux+fbsdbug> |
| Component: | conf | Assignee: | George V. Neville-Neil <gnn> |
| Status: | Closed FIXED | ||
| Severity: | Affects Many People | CC: | 000.fbsd, Jungleboogie0, ae, bz, darkfiberiru, emaste, fbugs, feld, freebsd, freebsd, garga, geezabiscuit2, kamil.choudhury, karl, koobs, marcis.lielturks, meyer.sydney, mh, net, seanc, xistence |
| Priority: | Normal | Keywords: | feature, patch |
| Version: | CURRENT | Flags: | koobs:
mfc-stable11?
koobs: mfc-stable10? koobs: mfc-stable9? |
| Hardware: | Any | ||
| OS: | Any | ||
| Bug Depends on: | |||
| Bug Blocks: | 212018 | ||
|
Description
Lionel Fourquaux
2008-10-12 12:10:00 UTC
Responsible Changed From-To: freebsd-bugs->freebsd-net Over to maintainer(s) for consideration Hi, the problem here is that enabling IPsec adds overhead to the entire IPv4/v6 network stack handling. A lot of people are currently working on performnce optimizations for all kinds of different setups. All those would be hurt if IPSEC would be on by default and they wouldn't need it. That's all kinds of various ISP server business for example. If we want to enable IPSEC by default on GENERIC the criteria to fix is "it must not measurably add up to processing times/reduce pps/.." if the connections do not use it. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. State Changed From-To: open->suspended Susepend until enough work on fixing IPsec and performance wise integration into the main network stack code flow has been/can be done. Responsible Changed From-To: freebsd-net->bz I'll take it so I'll have it in mind. Responsible Changed From-To: bz->gnn I shall not use bugzilla (at least until we will have a CLI). Hi *, I vote for an enabled IPSEC option in GENERIC too. I would appreciate it very much to have this option. Or is it maybe possible to have it as an loadable module ? It would make the life easier with a freebsd ipsec client software running (like security/ike) Thanks, Cliff I too would also like it in GENERIC (or a loadable module if possible). Having to compile a custom kernel just to get IPSEC is a pain. I've just run freebsd-update on a system and now lost my IPSEC capability :( So I have to choose between either having IPSEC and having to do source upgrades all the time, or not having ISPEC and use the binary update system. Thanks! -Matt I'd like to request ipsec be enabled in generic. The depends on is the documentation: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html +1 You'll catch more flies with IPSEC honey I understand there are known performance effects of enabling this, so I think it should be considered a priority to minimize/correct the deficiencies. I am actively looking into this. I will start a round of tests and then see what we need to do to make this work for 11. +1 IPSEC should really be part of the GENERIC kernel. A commit references this bug: Author: gnn Date: Sat Jul 4 17:37:03 UTC 2015 New revision: 285142 URL: https://svnweb.freebsd.org/changeset/base/285142 Log: Enable IPSEC in all GENERIC kernels. Universe and kernel build tests passed 4 July 2015 PR: 128030 Sponsored by: Rubicon Communications (Netgate) Changes: head/sys/amd64/conf/GENERIC head/sys/arm64/conf/GENERIC head/sys/i386/conf/GENERIC head/sys/pc98/conf/GENERIC head/sys/powerpc/conf/GENERIC head/sys/sparc64/conf/GENERIC Thank you George! Are merges to stable/10 and stable/9 possible? Please MFC if so. If not, please set mfc-* flag values to - with a comment so that users know why not, thank you! Pending MFC to stable/9 & stable/10 First of all: thanks so much for doing this. Is there any chance we could MFC this to 9/STABLE and 10/STABLE? Any update on the MFC to 10.x? (In reply to Nick B from comment #16) I suspect we won't see it MFC to 10.x unless the performance impact is deemed acceptable. It's supposedly minor, but the further improvements to make IPSEC have a negligible penalty likely cannot be MFC'd to 10.x. gnn should have more details as he was involved in the actual analysis of the impact. (In reply to Mark Felder from comment #17) Mark, appreciate your response on this. That said, it is very impractical to have to compile a new kernel in order to have IPSEC support, a feature FreeBSD in 2015 (and now 2016) should support natively without hassle. Is there no way to have it enabled in kernel, but disabled by default in a sysctl OID of some kind if there is a performance hit? That way, the user could just turn on the IPSEC network code via sysctl. Also, what kind of hit are we talking on a modern server? > Is there no way to have it enabled in kernel, but disabled by default in a sysctl OID of some kind if there is a performance hit?
Yes, that is exactly the work that was done in -CURRENT to allow it to be compiled in by default, but have a minimal effect on performance unless turned on. I'm not sure how difficult the MFC would be.
I'm not sure if this is would require a separate request but I'd like to see IPSEC_NAT_T enabled in the GENERIC kernel also. I use my laptop as a mobile IPSEC client and have to deal with connecting through natted IPs. Currently I need to run a custom kernel just to add IPSEC and IPSEC_NAT_T support and it makes keeping my system up to date somewhat cumbersome. (In reply to geezabiscuit2 from comment #20) This issue has already been committed to head and is pending MFC (see comment 13, comment 14, comment 16) I'd suggest create a separate issue with a similar summary (replacing IPSec with IPSEC_NAT_T of course) and add this issue's URL to the new issues "See Also:" field (In reply to geezabiscuit2 from comment #20) While we're on the topic... options IPSEC_FILTERTUNNEL ought to be in GENERIC as well.... and, arguably device enc StrongSwan currently requires (even in 11.x) a custom kernel because these two entries are not in GENERIC. +1 for IPSEC_NAT_T in GENERIC. I've created a new request to add IPSEC_NAT_T: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212018 (In reply to karl from comment #22) The kernel option IPSEC_FILTERTUNNEL should be removed ... as indicated in commit .. uhm .. https://svnweb.freebsd.org/base?view=revision&revision=192648 ; my bad; should have done that 6 years ago ... please use the loader tunable; no need to compile a different kernel for this anymore. (In reply to Bjoern A. Zeeb from comment #25) Whoops. make that a sysctl (he who can read his own commit messages ...) so you can change it at runtime; even better; no need to reboot or compile a kernel ;-) (In reply to karl from comment #22) > and, arguably > > device enc > > StrongSwan currently requires (even in 11.x) a custom kernel because these > two entries are not in GENERIC. I made if_enc loadable in 11.0. (In reply to Andrey V. Elsukov from comment #27) Excellent... thank you; this implies that if IPSEC_NAT_T is put in GENERIC's config then a modified kernel is no longer necessary for StrongSwan (and other IPSEC users who wish to run through encrypted traffic through ipfw or similar, and most will.) Any additional updates related to IPSEC can be their own PRs. The work spoken of here is now complete. Author: gallatin Date: Thu May 9 22:38:15 2019 New Revision: 347410 URL: https://svnweb.freebsd.org/changeset/base/347410 Log: Remove IPSEC from GENERIC due to performance issues Having IPSEC compiled into the kernel imposes a non-trivial performance penalty on multi-threaded workloads due to IPSEC refcounting. In my benchmarks of multi-threaded UDP transmit (connected sockets), I've seen a roughly 20% performance penalty when the IPSEC option is included in the kernel (16.8Mpps vs 13.8Mpps with 32 senders on a 14 core / 28 HTT Xeon 2697v3)). This is largely due to key_addref() incrementing and decrementing an atomic reference count on the default policy. This cause all CPUs to stall on the same cacheline, as it bounces between different CPUs. Given that relatively few users use ipsec, and that it can be loaded as a module, it seems reasonable to ask those users to load the ipsec module so as to avoid imposing this penalty on the GENERIC kernel. Its my hope that this will make FreeBSD look better in "out of the box" benchmark comparisons with other operating systems. Many thanks to ae for fixing auto-loading of ipsec.ko when ifconfig tries to configure ipsec, and to cy for volunteering to ensure the the racoon ports will load the ipsec.ko module Reviewed by: cem, cy, delphij, gnn, jhb, jpaetzel Differential Revision: https://reviews.freebsd.org/D20163 Modified: head/UPDATING head/sys/amd64/conf/GENERIC head/sys/arm/conf/std.armv6 head/sys/arm/conf/std.armv7 head/sys/arm64/conf/GENERIC head/sys/i386/conf/GENERIC head/sys/powerpc/conf/GENERIC head/sys/powerpc/conf/GENERIC64 head/sys/riscv/conf/GENERIC head/sys/sparc64/conf/GENERIC Was or will be ipsec related ports maintainers notified about this change / need of kldload? E.g. security/strongswan |
