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

[Jiannan Ouyang]

Hi Harald and Jeo,

Thank you for the code review. They are really helpful!

> On 7/13/17, 11:14 AM, "Joe Stringer"  wrote:
> 
> On 13 July 2017 at 00:12, Harald Welte  wrote:
>> I'm not familiar with the details here, but does this imply that you
>> are matching on the outer (transport layer) source IP address? If so,
>> please note this is in violation of the 3GPP specifications for GTP,
>> which require explicitly that the TEID is the *only* criteria for
>> matching an encapsulated packet to the tunnel.  Basically anyone can
>> send you an encapsulated packet from any random source IP, just as long
>> as the TEID matches a tunnel, it will be decapsulated.
>>
>> This is [presumably] in order to take care of mobility, as the
>> subscribers' phone moves around different MME/S-GW/SGSN, each having
>> different source IP addresses.
>
> I think that this will be hard to avoid; the several existing tunnel
> implementations that OVS plugs into all allow matching on the outer
> addresses/ports, I don't see a good way to restrict it without
> introducing completely new metadata_dst paths for GTP. I'd prefer not
> to introduce something like this if we can avoid it; several tunnels
> currently share all of the same metadata_dst code and that's proven
> sufficient for all cases so far. If someone wishes to implement the
> 3GPP standard correctly then they should not create matches like this.
> In quite a few cases, OVS tends to take the approach that we give the
> user the tools to do what they need to do, but if they wish to shoot
> themselves in the foot then that's up to them. We can of course work
>  towards ensuring the OVS userspace guides users in the right direction
> though.

The flow listed out here is an example for the nature of the match
that can be performed, but the actual match rule that is programmed
 by the control plane should wildcard the tun_src as noted by Harald. 

It is the control plane’s responsibility to enforce the 3GPP Specifications, 
e.g. creating flow rules to make TEID the only criteria for matching an 
encapsulated packet to the tunnel.  

I will provide a 3GPP compliant example in the next version, thank Harald
 for pointing it out.

-Jiannan

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

[Joe Stringer]

On 13 July 2017 at 00:12, Harald Welte  wrote:
> hi Jiannan,
>
> net-next si closed, as it has been pointed out already by Joe.
>
> On Wed, Jul 12, 2017 at 05:44:52PM -0700, Jiannan Ouyang wrote:
>> 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"
>
> I'm not familiar with the details here, but does this imply that you
> are matching on the outer (transport layer) source IP address? If so,
> please note this is in violation of the 3GPP specifications for GTP,
> which require explicitly that the TEID is the *only* criteria for
> matching an encapsulated packet to the tunnel.  Basically anyone can
> send you an encapsulated packet from any random source IP, just as long
> as the TEID matches a tunnel, it will be decapsulated.
>
> This is [presumably] in order to take care of mobility, as the
> subscribers' phone moves around different MME/S-GW/SGSN, each having
> different source IP addresses.

I think that this will be hard to avoid; the several existing tunnel
implementations that OVS plugs into all allow matching on the outer
addresses/ports, I don't see a good way to restrict it without
introducing completely new metadata_dst paths for GTP. I'd prefer not
to introduce something like this if we can avoid it; several tunnels
currently share all of the same metadata_dst code and that's proven
sufficient for all cases so far. If someone wishes to implement the
3GPP standard correctly then they should not create matches like this.
In quite a few cases, OVS tends to take the approach that we give the
user the tools to do what they need to do, but if they wish to shoot
themselves in the foot then that's up to them. We can of course work
towards ensuring the OVS userspace guides users in the right direction
though.

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

[Harald Welte]

hi Jiannan,

net-next si closed, as it has been pointed out already by Joe.

On Wed, Jul 12, 2017 at 05:44:52PM -0700, Jiannan Ouyang wrote:
> 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"

I'm not familiar with the details here, but does this imply that you
are matching on the outer (transport layer) source IP address? If so,
please note this is in violation of the 3GPP specifications for GTP,
which require explicitly that the TEID is the *only* criteria for
matching an encapsulated packet to the tunnel.  Basically anyone can
send you an encapsulated packet from any random source IP, just as long
as the TEID matches a tunnel, it will be decapsulated.

This is [presumably] in order to take care of mobility, as the
subscribers' phone moves around different MME/S-GW/SGSN, each having
different source IP addresses.

-- 
- Harald Welte    http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

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

[Joe Stringer]

On 12 July 2017 at 17:44, Jiannan Ouyang  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

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

[Jiannan Ouyang]

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

 drivers/net/gtp.c| 375 ---
 include/net/gtp.h|   8 +
 include/uapi/linux/openvswitch.h |   1 +
 net/openvswitch/Kconfig  |  10 ++
 net/openvswitch/Makefile |   1 +
 net/openvswitch/vport-gtp.c  | 144 +++
 6 files changed, 475 insertions(+), 64 deletions(-)
 create mode 100644 net/openvswitch/vport-gtp.c

-- 
2.9.3