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.
(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
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. 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 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...
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
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
Hi Andreas,
first of all thanks for your valid clarifications.
On Tue, Oct 27, 2015 at 04:50:37PM +0100, Andreas Schultz wrote:
IMHO, GTP (in 3GPP land) is not spoken over unsecured networks. So there is no need for security.
That's what you think, and what _should_ be th case. Don't think that this is the reality, though. Same is true for SIGTRAN :/
On Tue, Oct 27, 2015 at 04:50:37PM +0100, Andreas Schultz wrote:
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.
Wow, how did I not see that! Thanks! Still learning my ways around GTP...
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.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
So SGSN and GGSN can pick any IP addresses independently for the two planes, and they can *send from* any port they choose; but they must always *listen* on precisely ports 2123 and 2152.
Meaning that even if gtphub received something from port 111 or 222, it must discard that port information and reply on either 2123 or 2152.
Hyyypothetically, the GGSN could choose to reply to the port it received from (111 or 222), which it actually does for Echos, but otherwise, that's not how GTP do.
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.
Well, indeed... I see it now :)
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.
Indeed.
Thanks a lot for clarifying this!
In pratice that means I simply cannot simulate several GSNs on the same IP address, because each wants to hog ports 2123 and 2152... Even if the secondary GSNs are just netcats, the first GSN would send to itself. To enable a test setup like this, I would need some non-standard config option, but that would compromise the meaning of the test. Well then.
Which brings us back to OpenGGSN: it doesn't heed these specs! OpenGGSN always does reply back to where things came from. When I configure gtphub to listen on and also send GTP-C from port 2222, OpenGGSN happily plays along and replies GTP-C to port 2222. I *can* have gtphub and OpenGGSN on the same IP address, just tested that it works.
So anyone using OpenGGSN probably uses ports 2123 and 2152 merely by incidence, because the SGSN side happens to send from these ports, too. If an SGSN picked a separate sending port, OpenGGSN would stop working.
I presume that's a fail on OpenGGSN's side, not a choice, right?
And this shows that users up to now don't seem to pick separate sending ports, kind of making the use of exactly the ports 2123 and 2152 for both sending and receiving a de facto standard...?
Thanks again!
~Neels
-
Andreas Schultz -
Harald Welte -
Neels Hofmeyr