IPsec VTI support for FreeBSD and Linux

[dhatz]

Since the subject IPsec VTI support (note: VTI is Cisco terminology, Juniper call it "Secure Tunnel Interface", Fortinet call it "Interface mode IPSEC" and they're all compatible with eachother) comes up regularly in pfSense's IPsec subforum, I thought people might find this recent discussion in freebsd-net interesting:

http://lists.freebsd.org/pipermail/freebsd-net/2012-June/032556.html

Eugene M. Zheganin emz at norma.perm.ru
Fri Jun 8 17:31:12 UTC 2012
if_ipsec

have an idea about new networking feature in FreeBSD.
I guess everyone is having ideas from time to time, and lots of these
idea having people think that they just had a decent idea. However, only
ideas that are complemented by a working code can be considered by the
community, and only some of them got commited into the tree, I am fully
aware of this fact.

Unfortunately, I am not able to produce the code. I guess this is the
point where most of the subscribers will (or at least should) stop
reading this post. Still, I'm addressing this post for people that have
the time and will to do something interesting. I guess that someone may
find this interesting. Myself, I find that this could be really useful.

(You can skip this part and the next part if you only want to read about
the idea) I work about 10 years as a network engineer. My company holds
country-wide supermarkets business. I am personally responsible for the
network infrastructure of the company. As the company has lots of
(hundreds) of branch offices, lots of my time I'm constructing new VPNs
between them. My company network infrastructure is build using FreeBSD
servers and Cisco (and last year - Juniper) equipment. So I am aware and
capable of building VPN of almost any modern type, and this is the post
about building it on FreeBSD (this annoying passage was written to give
you impression that I'm not just a guy with FreeBSD server at home,
holding a couple of movies).

So. About VPNs. Another annoying passage about common ways and caveats.
Otherwise most of the reading ppl will say 'Why the hell if_ipsec ?'
(ppl that are aware of the VPNs can really skip this part). The
conventional way to build vpn is to build a tunnel of some sort. This
can be an encrypted tunnel, or an unencrypted tunnel. Unencrypted
tunnel  (gre/ipinip) is obviously unencrypted, but gives you an
interface which could be using in routing. Encrypted tunnel (and I'm
talking about ipsec) cannot be used for rounting, but is encrypted.
Plus, you have to care about policies, and when multiple routers are
involved, with hundreds of networks behind them, you have to care about
tonns of policies, and this is painful. So, the industry invented a
method: you use a gre/ipinip tunnel, you pass the dynamic routing
information (you don't care bout networks, you only care abouth the
endpoints), and you encrypt this tunnel with ipsec. So, gre + ipsec (of
gif + ipsec). This way is supported by all of the major vendors, you can
build gre(ipinip)+ipsec tunnel to any Cisco/Juniper device. Though
building in to JunOS requires some skill and a deep knowledge. :)

(here the idea starts) But what is an gre or gif tunnel ? This is not an
interface, but a way to tell the system, that it needs to encapsulate
some of the payload with another header, and send it somewhere. So,
using ipsec you add an extra header, and using gre(ipinip) you add an
extra header. What if we will add an additional ability to understand
that some of the ipsec packets are destined to the security gateway
(which adds the extra header) itself,  like it's possible with
gre/ipinip, so we can get rid of one extra header ? Cisco/Juniper did
that. So, Cisco has the 'tun mode ipsec ipvX' interface, and Juniper has
the st (secure tunnel) interface. How does it work: it's a convenstional
ISAKMP  IPsec with the ability to treat some of the packets with a
particular IP like destined to the local (by this I mean 'this') host.
Besides this it's the old IPsec. It's even interoperable between
different vendors devices. I don't see any reason why FreeBSD cannot
have this ability, since it does have a working Ipsec and working
ISAKMP. In order to obtain this functionality FreeBSD needs to have a
way to define the templates for the SPD entries, and  the way to create
these SPD entries after the creation of the interface, based on it's
address information. This will really simplify the VPN creating and
management.

So… here was the idea. :)
It came to my head after configuring the Juniper/Cisco VPN (and the
config was really short), and after reading quagga-users@ maillist,
where some of the subscribers asked about 'tun mode ipsec'. Plus, as far
as I know, Linux does not support this too, so we could really score
some points.

Anyway, based on the subsequent discussion, it seems that VTI is not supported by FreeBSD.

Coincidentally, just a few days ago there have been commits posted in Linux netdev about this feature:

http://lists.openwall.net/netdev/2012/06/08/88
Date: Fri, 8 Jun 2012 10:33:08 -0700
From: Saurabh <saurabh.mohan@…tta.com>To: netdev@...r.kernel.org
Subject: [PATCH 00/02] iproute2: Add support for new tunnel type VTI.

Introduction:
Virtual tunnel interface is a way to represent policy based IPsec tunnels as virtual interfaces in linux. This is similar to Cisco's VTI (virtual tunnel interface) and Juniper's representaion of secure tunnel (st.xx). The advantage of representing an IPsec tunnel as an interface is that it is possible to plug Ipsec tunnels into the routing protocol infrastructure of a router. Therefore it becomes possible to influence the packet path by toggling the link state of the tunnel or based on routing metrics.

Overview:
Natively linux kernel does not support ipsec as an interface. Also secure interface assume a ipsec policy 4 tupple of {dst-ip-any, src-ip-any, dst-port-any, src-port-any}. Applying this 4 tuple in linux would result in all traffic matching the ipsec policy. What is needed is a tunnel distinguisher. The linux kernel skbuff has fwmark which is used for policy based routing (PBR). Linux kernel version 2.6.35 enhanced SPD/SADB to use fwmark as part of the IPsec policy. Strongswan has also introduced support for this kernel feature with version 4.5.0. We can therefore use the fwmark as the distinguisher for tunnel interface. We can also create a light weight tunnel kernel module (vti) to give the notion of an interface for rest of the kernel routing system. The tunnel module does not do any encapsulation/decapsulation. The kernel's xfrm modules still do the esp encryption/decryption.

Enhancement to iproute2:
Add support to configure and display VTI tunnel using ioctl and rtnetlink.

Usage:
ip tunnel add sti15 mode vti remote 12.0.0.1 local 12.0.0.3 ikey 15
or
ip link add sti15 type vti key 15 remote 12.0.0.1 local 12.0.0.3

Signed-off-by: Saurabh Mohan<saurabh.mohan@…tta.com></saurabh.mohan@…tta.com></saurabh.mohan@…tta.com>