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. regards Mostafa ________________________________________ From: Ansis Atteka <aatt...@nicira.com> Sent: Monday, January 18, 2016 4:42 PM To: mostafa uddin Cc: discuss@openvswitch.org Subject: Re: [ovs-discuss] IPSec and Open vSwitch On Mon, Jan 18, 2016 at 10:16 AM, mostafa uddin <mud...@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 OVS datapath. 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. Regards, Ansis _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
