GTP ports and IP addresses

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