[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170713071249.lk7dph6bpzgn622d@nataraja>
Date: Thu, 13 Jul 2017 09:12:49 +0200
From: Harald Welte <laforge@...monks.org>
To: Jiannan Ouyang <ouyangj@...com>
Cc: osmocom-net-gprs@...ts.osmocom.org, netdev@...r.kernel.org,
dev@...nvswitch.org, pablo@...filter.org, pshelar@...ira.com,
wieger.ijntema.tno@...il.com, yi.y.yang@...el.com, joe@....org,
amarpadmanabhan@...com
Subject: Re: [PATCH net-next v1 0/3] Flow Based GTP Tunneling
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 <laforge@...monks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Powered by blists - more mailing lists