netdev - Re: [PATCH net-next v1 0/3] Flow Based GTP Tunneling

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPWQB7Fv5VHwVt-65w9v=VvqXcprT6cRBQyKv5U8gZ+gL1WH7w@mail.gmail.com>
Date:   Wed, 12 Jul 2017 18:28:29 -0700
From:   Joe Stringer <joe@....org>
To:     Jiannan Ouyang <ouyangj@...com>
Cc:     osmocom-net-gprs@...ts.osmocom.org,
        netdev <netdev@...r.kernel.org>, ovs dev <dev@...nvswitch.org>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        laforge@...monks.org, Pravin B Shelar <pshelar@...ira.com>,
        Wieger IJntema <wieger.ijntema.tno@...il.com>,
        "Yang, Yi Y" <yi.y.yang@...el.com>, amarpadmanabhan@...com
Subject: Re: [PATCH net-next v1 0/3] Flow Based GTP Tunneling

On 12 July 2017 at 17:44, Jiannan Ouyang <ouyangj@...com> wrote:
> This patch series augmented the existing GTP module to support flow
> based GTP tunneling and modified the openvswitch datapath to support the
> GTP vport type.
>
> A flow based GTP net device enables that,
> 1) on the RX path, the outer (IP/UDP/GTP) header information could to be
> stored in the metadata_dst struct, and embedded into the skb.
> 2) on the TX path, packets are encapsulated following instructions in
> the metadata_dst field of the skb.
>
> A flow based GTP net device can be integrated with Open vSwitch, which
> allows SDN controllers to program GTP tunnels via Open vSwitch.
>
> Open vSwitch changes are based on patch set
>     [PATCH] Add GTP vport based on upstream datapath
>
> Example usage with OVS:
>
> ovs-vsctl add-port br0 gtp-vport -- set interface gtp-vport \
>     ofport_request=2 type=gtp option:remote_ip=flow options:key=flow
>
> ovs-ofctl add-flow br0
>     "in_port=2,tun_src=192.168.60.141,tun_id=123, \
>     actions=set_field:02:00:00:00:00:00->eth_src, \
>     set_field:ff:ff:ff:ff:ff:ff->eth_dst,LOCAL"
>
> ovs-ofctl add-flow br0 \
>     "in_port=LOCAL,actions=set_tunnel:888, \
>     set_field:192.168.60.141->tun_dst,2"
>
> arp -s 10.1.1.122 02:00:00:00:00:00
>
> Jiannan Ouyang (3):
>   gtp: refactor to support flow-based gtp encap and decap
>   gtp: Support creating flow-based gtp net_device
>   openvswitch: Add GPRS Tunnel Protocol (GTP) vport support

Hi Jiannan,

net-next is closed, Dave won't accept patches at this time.

Some brief feedback in regards to patch #3, the preference these days
is for OVS userspace to use rtnetlink to configure devices in
COLLECT_METADATA mode, then attach those devices as regular
vport-netdev device type to OVS kernel datapath. I think that should
mean that no kernel changes to openvswitch are required for providing
GTP vports. Instead of this patch it would require something similar
to the IFLA_GRE_COLLECT_METADATA flag which GRE has, but for the GTP
devices. The latest OVS master now supports configuring devices in
this way, perhaps you could take a look at OVS tree's
lib/dpif-netlink-rtnl.c to see how other tunnel devices are configured
and see if that makes sense for GTP as well?

Cheers,
Joe