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