[PATCH net-next v1 0/3] Flow Based GTP Tunneling
laforge at gnumonks.org
Thu Jul 13 07:12:49 UTC 2017
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, \
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 <laforge at gnumonks.org> http://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
More information about the osmocom-net-gprs