27 Oct
2015
27 Oct
'15
5:50 p.m.
Hi Neels,
I'm quite new to the GTP game, so take my comments with a grain of salt.
More inline...
On 10/27/2015 04:19 PM, Neels Hofmeyr wrote:
Hi all,
a remark / question about GTP, in the context of writing code for
gtphub...
So far I've tried to keep the GTP IP addresses and ports config general --
you never know what weird things one might want to do some day (different
IP addresses for User and Control? Nonstandard port numbers?).
But now I'm at the point where I've got a Control plane message from a
"control peer", and need to figure out the matching peer on the User
plane. How do I do that? By IP address, of course.
Thus it struck me that GTP *depends* on a setup where the User IP address
is identical to the IP of the sender of the Ctrl plane packet.
I don't think so.
In 3GPP TS 29.060 version 12.9.0, the table of information elements for
Create PDP Context Request does list SGSN Address for signalling AND
SGSN Address for user traffic, both are mandatory.
(view with a monospaced font)
SGSN GGSN (or gtphub)
1.2.3.4 5.6.7.8
Ctrl: 2123 <-------> 2123
User: 2152 <-------> 2152
So trying to stay general with IP addresses is an exercise in futility,
because it plainly doesn't work for GTP: I can't match up a peer's two
message planes unless the above standard is given.
Thinking of a nonstandard situation:
GGSN (or gtphub)
SGSN 5.6.7.8
Ctrl: 1.2.3.4:111 <-------> 2123
User: 4.3.2.1:222 X-------> 2152
You arrows imply bidirectional connection. The above wouldn't be allowed in
that case. But something like would. 3GPP TS 29.281 version 12.1.0 does
say this:
Section 4.4.2.0 General:
For the messages described below, the UDP Source Port
(except as specified
for the Echo Response message) may be > allocated either statically or
dynamically by the sending GTP-U entity.
Section 4.4.2.2 Echo Response Message:
The UDP Destination Port value shall be the value of
the UDP Source Port of
the corresponding request message.
Section 4.4.2.3 Encapsulated T-PDUs:
The UDP Destination Port number shall be 2152. It is
the registered port
number for GTP-U.
This means the following situation is completely valid:
GGSN (or gtphub)
SGSN 5.6.7.8
Ctrl: 1.2.3.4:111 -------> 2123
1.2.3.4:2123 <------- 5678
User: 4.3.2.1:222 -------> 2152
4.3.2.1:2152 <------- 9012
The GGSN can record that there's a Ctrl peer at
1.2.3.4:111, from the
incoming GTP packet's sender address. Say it receives a Create PDP Context
Request, in which the nonstandard SGSN sends two TEIs it wants to use, on
the Ctrl *and* User plane. Now, the GGSN cannot possibly know that 4.3.2.1
is the User plane peer for which the TEI from the Create PDP Ctx Req
should be valid.
As fas as I understand, the GGSN would get these IEs:
* Tunnel Endpoint Identifier Control Plane + SGSN Address for user traffic
* Tunnel Endpoint Identifier Data I + SGSN Address for signalling
It would then reply with:
* GGSN Address for Control Plane + Tunnel Endpoint Identifier Control Plane
* GGSN Address for user traffic + Tunnel Endpoint Identifier Data I
Together this should transport all the information required to match
the tunnels.
One may think that the SGSN can just contact the GGSN
from 4.3.2.1:222 and send the TEI from the Create PDP, so the GGSN could
know that it's the same peer. But in fact a TEI is scoped *within* a comm
plane with a peer, meaning that any other peer could choose the exact same
TEI at any point, and the means to disambiguate is the peer's IP address.
So my wishful thinking to stay general there is thwarted by design. The
Ctrl and User IP addresses must be identical.
Still, the SGSN's port numbers could theoretically be chosen freely. The
GGSN knows the sender of the Ctrl packet(s), and as soon as a User packet
comes in from the same IP address, it also knows the User plane port. As
As pointed out earlier, the ports are no bidirectional. It is mandatory that
GTP-U receives at port 2152 and GTP-C v1 receives at 2123. The sending ports
can be chosen freely.
long as the IP address is the same and there are no
other SGSNs using
different ports on the same IP address, the GGSN could figure out both
nonstandard Ctrl and User ports like this.
BTW, we've also thought about securing the GTP wire towards gtphub with
some kind of authentication (future). With identification sent on both
planes, the limitations discussed here would be void...
IMHO, GTP (in 3GPP land) is not spoken over unsecured networks. So there
is no need for security.
So I'll actually keep gtphub's config as
general as it is, but will not
invest time, neither in implications of choosing nonstandard setups, nor
in prohibiting them (yet).
The nonstandard ports config capability actually comes in handy for unit
testing, where I can place some netcats and a gtphub on arbitrary port
numbers on the same IP address. (Since implicit creation of 127.0.0.N
interfaces is linux specific, using several local addresses without root
privilege is not portable).
If you spot any thinkos there, please let me know :)
~Neels
Regards
Andreas