This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Andreas Schultz aschultz at tpip.netHi 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