* [net-next PATCH 00/02] net/ipv4: Add support for new tunnel type VTI.
@ 2012-06-28 1:02 Saurabh
0 siblings, 0 replies; 8+ messages in thread
From: Saurabh @ 2012-06-28 1:02 UTC (permalink / raw)
To: netdev
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 enc
apsulation/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@vyatta.com>
Reviewed-by: Stephen Hemminger <shemminger@vyatta.com>
---
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [net-next PATCH 00/02] net/ipv4: Add support for new tunnel type VTI.
2012-07-17 19:44 Saurabh
@ 2012-07-18 16:36 ` David Miller
0 siblings, 0 replies; 8+ messages in thread
From: David Miller @ 2012-07-18 16:36 UTC (permalink / raw)
To: saurabh.mohan; +Cc: netdev
From: Saurabh <saurabh.mohan@vyatta.com>
Date: Tue, 17 Jul 2012 12:44:42 -0700
>
>
> 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.
All applied.
Please post the ipv6 side soon, thank you.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [net-next PATCH 00/02] net/ipv4: Add support for new tunnel type VTI.
@ 2012-07-17 19:44 Saurabh
2012-07-18 16:36 ` David Miller
0 siblings, 1 reply; 8+ messages in thread
From: Saurabh @ 2012-07-17 19:44 UTC (permalink / raw)
To: netdev
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@vyatta.com>
Reviewed-by: Stephen Hemminger <shemminger@vyatta.com>
---
^ permalink raw reply [flat|nested] 8+ messages in thread
* [net-next PATCH 00/02] net/ipv4: Add support for new tunnel type VTI.
@ 2012-06-29 1:29 Saurabh
0 siblings, 0 replies; 8+ messages in thread
From: Saurabh @ 2012-06-29 1:29 UTC (permalink / raw)
To: netdev
Addressed formating feedback from David.
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@vyatta.com>
Reviewed-by: Stephen Hemminger <shemminger@vyatta.com>
---
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [net-next PATCH 00/02] net/ipv4: Add support for new tunnel type VTI.
2012-06-29 0:52 Saurabh
@ 2012-06-29 1:01 ` David Miller
0 siblings, 0 replies; 8+ messages in thread
From: David Miller @ 2012-06-29 1:01 UTC (permalink / raw)
To: saurabh.mohan; +Cc: netdev
From: Saurabh <saurabh.mohan@vyatta.com>
Date: Thu, 28 Jun 2012 17:52:14 -0700
> 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.
Please format your text paragraphs for ~80 character lines, this is a
single 500+ character line in my email client and painful to read.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [net-next PATCH 00/02] net/ipv4: Add support for new tunnel type VTI.
@ 2012-06-29 0:52 Saurabh
2012-06-29 1:01 ` David Miller
0 siblings, 1 reply; 8+ messages in thread
From: Saurabh @ 2012-06-29 0:52 UTC (permalink / raw)
To: netdev
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 enc
apsulation/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@vyatta.com>
Reviewed-by: Stephen Hemminger <shemminger@vyatta.com>
---
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [net-next PATCH 00/02] net/ipv4: Add support for new tunnel type VTI.
2012-06-08 17:32 Saurabh
@ 2012-06-12 16:17 ` Nicolas Dichtel
0 siblings, 0 replies; 8+ messages in thread
From: Nicolas Dichtel @ 2012-06-12 16:17 UTC (permalink / raw)
To: Saurabh; +Cc: netdev
Hi,
thank you for pushing this feature upstream Saurabh.
This feature is very usefull, we have implemented something similar in our system.
Regards,
Nicolas
Le 08/06/2012 19:32, Saurabh a écrit :
>
>
> 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
>
> Signed-off-by: Saurabh Mohan<saurabh.mohan@vyatta.com>
> Reviewed-by: Stephen Hemminger<shemminger@vyatta.com>
>
> ---
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 8+ messages in thread
* [net-next PATCH 00/02] net/ipv4: Add support for new tunnel type VTI.
@ 2012-06-08 17:32 Saurabh
2012-06-12 16:17 ` Nicolas Dichtel
0 siblings, 1 reply; 8+ messages in thread
From: Saurabh @ 2012-06-08 17:32 UTC (permalink / raw)
To: netdev
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 enc
apsulation/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
Signed-off-by: Saurabh Mohan <saurabh.mohan@vyatta.com>
Reviewed-by: Stephen Hemminger <shemminger@vyatta.com>
---
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-07-18 16:36 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-28 1:02 [net-next PATCH 00/02] net/ipv4: Add support for new tunnel type VTI Saurabh
-- strict thread matches above, loose matches on Subject: below --
2012-07-17 19:44 Saurabh
2012-07-18 16:36 ` David Miller
2012-06-29 1:29 Saurabh
2012-06-29 0:52 Saurabh
2012-06-29 1:01 ` David Miller
2012-06-08 17:32 Saurabh
2012-06-12 16:17 ` Nicolas Dichtel
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.