[ovs-dev] conntrack: nfqueue action

[Franck Baudin]

On 06/12/15 20:31, Ansis Atteka wrote:
> On Fri, Jun 12, 2015 at 5:50 AM, Franck Baudin <franck.baudin at qosmos.com> wrote:
>> Hi Ansis,
>>
>>
>> On 06/09/15 22:59, Ansis Atteka wrote:
>>> Hi Franck
>>> On 8 June 2015 at 09:34, Franck BAUDIN <Franck.BAUDIN at qosmos.com
>>> <mailto:Franck.BAUDIN at qosmos.com>> wrote:
>>>
>>>      Hello,
>>>
>>>      Conntrack looks in very good progress on
>>>      https://github.com/justinpettit/ovs.git
>>>
>>>
>>>
>>>      However, I didn't find any code related to "nfqueue" openvswitch
>>>      action, neither on
>>>      https://github.com/tgraf/ovs.git.
>>>
>>>      Is the nfqueue action still planned to be implemented for
>>>      openvswitch 2.4? Do you need a hand on this topic?
>>>
>>> Unfortunately, I am not aware of anyone working actively on this. There
>>> are some difficulties that we see with implementing NFQueue verdicts
>>> properly so that packet processing could be resumed. If you have design
>>> proposal on how to solve this, then I would be glad to hear your opinion.
>>>
>>> Also, do you think that Open vSwitch kernel module's userspace() action
>>> might somehow suffice your use cases so that user-space process would be
>>> able to get packet from kernel-space?
>> Unfortunately, userspace() is not an option as DPI is not embedded in
>> ovs-vswitchd. DPI is a standalone userland process.
> While I haven't tried it myself, It is possible for process other than
> ovs-vswitchd to get packets sent from OVS kernel module to userspace
> via userspace() action by making your process to subscribe to the
> right OVS NETLINK notifications. Of course we would still have to
> figure out how to implement corresponding OpenFlow DPI action that
> would translate into this Kernel userspace(dpi) action.
Thanks for the tip! I need to dig a bit to see if this would require a 
datapath patch, an to figure out if this way would perform better than tap.

>> However, I found another way which is pretty straightforward: I can use a
>> dedicated vswitch port to get a copy of the traffic I want to analyze with
>> the DPI. I just need one port per conntrack zone.
> Yes, it must be somehow possible to be able to pass "conntrack zone"
> context to the DPI engine. However, are you implying here that you
> would create Interfaces with type="internal" per conntrack zone?
Yes, I need to find a way to get the conntrack zone for every packet, so 
having a port per zone is an option. I can also use an encapsulation to 
encode the conntrack zone (vlan for instance) if there are numerous 
conntrack zones.

I used the following rules successfully to send the packets 'under DPI 
classification' (conn_mark=0 in this example, I'm gonna try conn_label 
as well as both should work) to the LOCAL port, and when I mark it at 
some point (conntrack -U -s 1.1.1.1 -p tcp --sport 37120 -m 8), I see 
that the packet is properly forwarded and no more copied to LOCAL:

ovs-ofctl del-flows br0
ovs-ofctl add-flow br0 
'priority=50000,tcp,conn_state=-trk,action=ct(commit,recirc)'
ovs-ofctl add-flow br0 
'priority=36000,tcp,conn_state=+trk,conn_mark=8,action=mod_nw_tos:8,NORMAL'
ovs-ofctl add-flow br0 
'priority=35000,tcp,conn_state=+trk,action=mod_nw_tos:4,LOCAL,NORMAL'
ovs-ofctl add-flow br0 'action=NORMAL'

Just to say that with Justin's current code, we have everything to 
implement DPI/L7 classification on openvswitch. Then, we'll see if 
optimizations/enhancements like NFQUEUE are relevant. Or did I miss 
something and this design doesn't fly?

Best Regards
Franck