[ovs-discuss] IPSec and Open vSwitch
muddin at cs.odu.edu
Sat Jan 23 15:56:15 UTC 2016
Thank you Ansis for your reply.
But here is what I understand:
You are right, for the egress packets IPSec processing is done after the OVS datapath if you are using vport-gre or vport-vxlan for the output port. But if you are using normal vport-netdev for the output port then packet does not get forwarded to XFRM.
But the problem is vport-gre or vport-vxlan put additional header (like GRE) that I don't want to have. I like to use purely IPSec tunneling, which I guess none of the existing vport in OVS datapath support.
Therefore, I am thinking to introduce new vport for IPsec tunneling only without any additional header. Do you think this approach will work.
Just to let you know, I am doing this for my research project, where I am running OVS in the android kernel. My project is to create an end-to-end programmable secure channel for the application's traffic.
From: Ansis Atteka <aatteka at nicira.com>
Sent: Monday, January 18, 2016 4:42 PM
To: mostafa uddin
Cc: discuss at openvswitch.org
Subject: Re: [ovs-discuss] IPSec and Open vSwitch
On Mon, Jan 18, 2016 at 10:16 AM, mostafa uddin <muddin at cs.odu.edu> wrote:
> I have a clarification question,
> Does the IPSec packet processing is done before the OVS datapath, in the
> network stack?
For incoming packets IPsec is done before reaching OVS datapath.
For egressing packets IPsec is done after the packet has already left
See http://inai.de/images/nf-packet-flow.png for more details where of
"local process" you could think as if it was OVS datapath that owns
tunneling socket. And IPsec is done in"XFRM" boxes.
> Is it possible to bring the IPSec packet processing inside the OVS Datapath?
> That means all the packet header formation, and encryption algorithm will be
> called when the packet is in the process path of OVS datapath module.
I haven't thought too much about this, but I am afraid that this might
get a little bit intrusive for Linux IP stack, because you would have
to get ESP packets somehow to OVS kernel module which means that OVS
would need to intercept *all* the ESP traffic that would otherwise
have went to XFRM boxes in that diagram.
If you have an idea how to do this in elegant way please propose.
More information about the discuss