netdev - [net-next PATCH 00/02] net/ipv4: Add support for new tunnel type VTI.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120717194442.GA3333@debian-saurabh-64.vyatta.com>
Date:	Tue, 17 Jul 2012 12:44:42 -0700
From:	Saurabh <saurabh.mohan@...tta.com>
To:	netdev@...r.kernel.org
Subject: [net-next PATCH 00/02] net/ipv4: Add support for new tunnel type
 VTI.

I have accommodated all the style comments so far. If there are any more
style comments then send all your feedback in one email rather than in bits
and pieces.

IPv6 support has not yet been developed. Once I have it developed and tested
I'll submit it as well.  If this feature will not be accepted without IPv6
then let me know and I'll stop wasting my time. 

Incorporated David and Steffen's comments.
Resubmitting after taking into account review comments:
The VTI tunnel is applicable to esp, ah and ipcomp.

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.

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

Sample strongswan config would be:
conn peer-12.0.0.1-tunnel-1
   left=12.0.0.3
   right=12.0.0.1
   leftsubnet=0.0.0.0/0
   rightsubnet=0.0.0.0/0
   ike=aes128-sha1-modp1024!
   ikelifetime=28800s
   keyingtries=%forever
   esp=aes128-sha1!
   keylife=3600s
   rekeymargin=540s
   type=tunnel
   pfs=yes
   compress=no
   authby=secret
   auto=start
   mark_in=0xf
   mark_out=0xf
   keyexchange=ikev1

Also you need the iptables rule for ingress esp and udp-4500 packets:
-A PREROUTING -s 12.0.0.1/32 -d 12.0.0.3/32 -p esp -j MARK --set-xmark 0xf/0xffffffff

Signed-off-by: Saurabh Mohan <saurabh.mohan@...tta.com>
Reviewed-by: Stephen Hemminger <shemminger@...tta.com>

---
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html