GTP ports and IP addresses

historical

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151027/85879a07/attachment.bin>