From owner-freebsd-net@freebsd.org Mon Nov 20 01:02:45 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8BD7DDBF0D for ; Mon, 20 Nov 2017 01:02:45 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 829CF69F1E for ; Mon, 20 Nov 2017 01:02:45 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mail-ot0-x22b.google.com with SMTP id u10so6359386otc.12 for ; Sun, 19 Nov 2017 17:02:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gtsj4J56jknfqsUk58GsnPWzGsfsEEgqAKniMOqARj8=; b=CpiA+PCcw5ZyLrqCxR9wLwNW6PG9gGa5HuxTKVHDZjS97Re7j0HDYohfOD+5jooAgs Y+DIOBs41+KC9i6jtu1SWIab+7E40BnV/4dS5hFZUEKYEdyyrvHZPzKGyLfLykn40OhP OVnidr3UFMUyyA8LsW4KAkjAVOlgGv5aGVSH0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gtsj4J56jknfqsUk58GsnPWzGsfsEEgqAKniMOqARj8=; b=DcRZm8csQZJf4PJ+pP86qhZzPAa8R4F89hemmcZPJKp9zxkx0LnOLSgqEiF9MEAvwP ZsqdH7hp5U5bkzr+VyKUQRW069X8yKNCY2rGjt1zNXSBBJE8HvqYLQ/5+TjS7aQVNCgB d1mTL0xEgbyG5FmMmCwDNa9vMir0rgurdb4pUUBoqdw3PvDu0D+fiUrLW0taCzWVIXHX 2+a3tYJneFMoOPdVwpkq0nANfYWFHxYh/n9JJxXhjBSO4xoOYjsPxLRtN7T3+mptXIPV qu2QAqBVuCfVQD04ATJqTPVR1Nz4NdJ0o3aN6Xhf4l+KLBbDWMAVY0CihT4vWwaIDNhy nfmA== X-Gm-Message-State: AJaThX78nCiVR5CiBTizQYuqYo5eCT5KI8gmBUW00lT6ZQywbah1Xj+g Dzr9AP9qJZSu7ECP5opM3ve6xKtPsPc= X-Google-Smtp-Source: AGs4zMbnm6OEbZFZJchFoFm27sLTisMucjPRW2U9uWxlxXdN5LGeO6z7QCaaIxBXo34nsW46+VOqog== X-Received: by 10.157.24.19 with SMTP id b19mr6544866ote.265.1511139764360; Sun, 19 Nov 2017 17:02:44 -0800 (PST) Received: from [172.21.0.169] (65-36-116-65.dyn.grandenetworks.net. [65.36.116.65]) by smtp.gmail.com with ESMTPSA id y2sm1842358otg.51.2017.11.19.17.02.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Nov 2017 17:02:43 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Subject: Re: OpenVPN vs IPSec From: Jim Thompson In-Reply-To: <20171119120832.GA82727@admin.sibptus.transneft.ru> Date: Sun, 19 Nov 2017 19:02:42 -0600 Cc: "Muenz, Michael" , FreeBSD Net Content-Transfer-Encoding: quoted-printable Message-Id: <2472B38E-694E-4E3A-8234-DB231B532728@netgate.com> References: <20171118165842.GA73810@admin.sibptus.transneft.ru> <20171119120832.GA82727@admin.sibptus.transneft.ru> To: Victor Sudakov X-Mailer: Apple Mail (2.3445.4.7) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 01:02:45 -0000 On Nov 19, 2017, at 6:08 AM, Victor Sudakov wrote: > Muenz, Michael wrote: >>>=20 >>> Is there any reason to prefer IPSec over OpenVPN for building VPNs >>> between FreeBSD hosts and routers (and others compatible with = OpenVPN >>> like pfSense, OpenWRT etc)? >>>=20 >>> I can see only advantages of OpenVPN (a single UDP port, a single >>> userland daemon, no kernel rebuild required, a standard PKI, an easy >>> way to push settings and routes to remote clients, nice monitoring >>> feature etc). But maybe there is some huge advantage of IPSec I've >>> skipped? >>>=20 >> Hi, >>=20 >> partners/customers with Cisco IOS or ASA wont be able to partner up=20= >> without IPSEC. >=20 > Sure, that's why I wrote "and others compatible with OpenVPN > like pfSense, OpenWRT etc" in the first paragraph. >=20 > Jim Thompson wrote: >>=20 >> Performance is better with IPsec. >=20 > Because it's in the kernel? But many use (and recommend) StrongSwan > which is a userland implementation. Yes, because it=E2=80=99s in the kernel. OpenVPN uses tun/tap and there = is considerable performance overhead due to multiple copies per packet = across the user-space / kernel boundary using these. This problem is = compounded by handing relatively small packets to OpenSSL=E2=80=99s EVP = layer for encrypt/decrypt and authentication. Here is a write-up from = 2011: https://homepages.staff.os3.nl/~delaat/rp/2010-2011/p09/report.pdf As you can read in the paper, the normal recommendation to overcome = these is to increase the MTU on the TAP interface, and disable = OpenVPV=E2=80=99s fragmentation routines. This serves to decrease these = overheads. See also: = https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux Note = that this write-up is a bit duplicitous as they=E2=80=99ve disabled = encryption and increased the =E2=80=9CMTU=E2=80=9D to reduce the = per-packet copy overhead and eliminate the encryption overhead.=20 More than once I=E2=80=99ve considered attempting to make OpenVPN work = on top of netmap, just to see how much overhead could be negated via = same. Use in a FreeBSD system would probably require VALE with a = steering plugin to direct the OpenVPN frames to the OpenVPN processes, = and the remainder to the kernel stack. On linux, one could use a SR-IOV = VF with netmap and allow the rest of the NIC to be used for the system. = Even with this, performance of OpenVPN will be constrained by the = packet-at-a-time single thread of execution implementation inside = OpenVPN=E2=80=99s code. While crypto can be offloaded, these can not. = A rewrite will be needed to get to true 1gbps performance (or above). To address another of your arguments: StrongSwan does, indeed, have a = user-land implementation of IPsec, most consumers (including pfSense) = use StrongSwan for IKE/IKEv2 keying of an in-kernel (FreeBSD, Linux) = IPsec implementation. Even StrongSwan=E2=80=99s primary author says the = userland IPsec has performance issues. = https://wiki.strongswan.org/projects/strongswan/wiki/Kernel-libipsec That said, we=E2=80=99ve benchmarked our userland IPsec implementation = at 36.32 Gbps over 40 Gbps Ethernet with crypto offload via Intel=E2=80=99= s QuickAssist, and yes, we use StrongSwan for IKEv2. The rest (40gbps - = 36.32) is framing overhead. See slide 11: = https://wiki.fd.io/images/1/1d/40_Gbps_IPsec_on_commodity_hardware.pdf. = On slide 10 you can see that we obtained 13.7Gbps single-stream = throughput using AES-GCM-128 and AES-NI. The next goal is to get to 100gbps using newer QAT cards and 100Gbps = NICs. OpenVPN will never get close to these results without a rewrite. Nor, = to address the elephant in the room, can it obtain the same performance = as IPsec on FreeBSD today. >> It's a standard, too.=20 >=20 > IPsec in itself maybe a standard, but IKE does not seem to be much of = a standard, I get the impression that there's much incompatibility = between vendors (Cisco, racoon etc).=20 RFC 4301, RFC 4303, etc all define IPsec proper. See section 1.3 of RFC = 4301 for a more complete list. = https://tools.ietf.org/html/rfc4301#section-1.3 RFC 7296 / STD 79 is the = primary document for IKEv2. https://tools.ietf.org/html/rfc7296 Yes, = there were implementation difficulties with ISAKMP/IKE (raccoon is IKE), = but IKEv2 (Oct 2014) is considerably better when it comes to both = security and interoperability of various implementations. Lessons were = learned. OTOH, there is no RFC for OpenVPN, it=E2=80=99s a vendor = implementation. Some documentation exists: = https://openvpn.net/index.php/open-source/documentation/security-overview.= html The other =E2=80=9CVPN=E2=80=9D that is getting increasing mention is = =E2=80=9CWireGuard=E2=80=9D https://www.wireguard.com/. WireGuard=E2=80=99= s performance page has additional comparisons between OpenVPN, IPsec = and, of course, WireGuard. https://www.wireguard.com/performance/. These = tests are on linux, not FreeBSD, because no port of WireGuard to FreeBSD = exists. This said, more than one individual has expressed interest in a = FreeBSD port of WireGuard. The main issue here is that WireGuard (like = OpenVPN and StrongSwan) is GPLed, but unlike these two, a performant = WireGuard implementation for FreeBSD would need to be in-kernel, and = that=E2=80=99s not going to occur while the code is still GPL. The = primary author of WireGuard has indicated a willingness to dual-license = WireGuard=E2=80=99s code, so the potential exists. Jim