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

Joe Stringer joe at ovn.org
Thu Jul 13 18:14:27 UTC 2017

On 13 July 2017 at 00:12, Harald Welte <laforge at gnumonks.org> 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=,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

More information about the osmocom-net-gprs mailing list