Monitoring mobile networks traffic has been traditionally perceived by the telecommunications industry as something complex, costly, proprietary. This is unfortunately one of the few fields where the open-source movement has not been able to spread much, where vendor lock-in is still the standard. Last year we visited the Mobile World Congress in Barcelona to understand more about this world (btw, it’s a crazy expo as the cheapest entry ticket costs 900$ and up), and the conclusion is that mobile terminals are pretty open thanks to Android, but the network is still very close. This has been the driving force for adding to nProbe the ability to analyse mobile traffic.
Our goal has been the monitoring of mobile network traffic, similar to what happens on standard IP networks in order to answer with some extras. In mobile networks, there is a protocol called GTP (GPRS Tunnelling Protocol) that is decomposed in two separate protocols:
- GTP-U: used to carry user-data traffic, i.e. the network traffic you make with your handheld when accessing the Internet (e.g. email, web surfing, gaming).
- GTP-C: used to carry signalling within the GPRS core network. Whenever you connect/disconnect, hop inside the network with your handheld, the network generates a message. Monitoring GTP-C is the key for keeping and association between a user (i.e. IMSI) and the dynamic IP address associated to the user within the mobile network. There is much more than this in GTP-C, such as the user phone number, the cell where the user is connected (and thus it’s physical location), the APN, and the handheld model. GTP-C is used to negotiate tunnel Ids, that are then used to carry user traffic, so GTP-C traffic state must be kept somewhere on a a database in order to keep the association between a user and its IP address.
GTP-C is handled with two plugins (gtpv1 and gtpv2 plugins), as well the radius protocol. The nProbe core instead has been updated to support many protocol and encapsulations used on mobile networks such as:
- PPP/Multilink PPP
- Mobile IP
- L2TP
- GTP v1 (2G/3G networks) and v2 (4G/LTE networks)
- GRE
- Radius with 3GPP extensions used on mobile networks.
All existing nProbe plugins have been updated so GTP-C is now first-class citizen. This means for instance that when nProbe sees some GTP-encapsulated HTTP traffic, along with the usual information (URL, Cookies, User-Agent….) information about the user who generated this traffic is also returned (i.e. the IMSI). This information correlation is implemented transparently in nProbe using the microcloud paradigm.
Whenever nProbe sees some GTP-C message, it dynamically (and automatically) updates the user status into the redis database, so that this information can be user to bind GTP-U to users.
Another advantage of the microcloud architecture, is that it allows traffic to be correlated across various probes. In fact mobile networks are distributed by nature, and it is usually not possible to aggregate all traffic into a single place. The microcloud allows all probes to share data (of course data caching is implemented on teach nProbe instance to avoid too many communications), so that all combinations are supported.
PF_RING clustering has also been updated so that whenever a server running nProbe, incoming traffic can shared across all running nProbe instances. This happens by honouring GTP tunnelling as PF_RING will not balance on the external packet envelope but on tunnelled traffic. Using this approach, PF_RING allows incoming network traffic (also on multiple incoming interfaces) to be balanced across multiple instances and thus to monitor multi-Gbit traffic on a single server.
Of course nDPI is able to dissect GTP-encapsulated traffic, and thus you can configure nProbe (by means of the specified template, -T) to analyse traffic at application level and thus learn the layer-7 protocol.
nProbe can export information via NetFlow v9/IPFIX using the following information elements:
Plugin GTPv1 Signaling Protocol templates: [NFv9 57692][IPFIX 35632.220] %GTPV1_REQ_MSG_TYPE GTPv1 Request Msg Type [NFv9 57693][IPFIX 35632.221] %GTPV1_RSP_MSG_TYPE GTPv1 Response Msg Type [NFv9 57694][IPFIX 35632.222] %GTPV1_C2S_TEID_DATA GTPv1 Client->Server TunnelId Data [NFv9 57695][IPFIX 35632.223] %GTPV1_C2S_TEID_CTRL GTPv1 Client->Server TunnelId Control [NFv9 57696][IPFIX 35632.224] %GTPV1_S2C_TEID_DATA GTPv1 Server->Client TunnelId Data [NFv9 57697][IPFIX 35632.225] %GTPV1_S2C_TEID_CTRL GTPv1 Server->Client TunnelId Control [NFv9 57698][IPFIX 35632.226] %GTPV1_END_USER_IP GTPv1 End User IP Address [NFv9 57699][IPFIX 35632.227] %GTPV1_END_USER_IMSI GTPv1 End User IMSI [NFv9 57700][IPFIX 35632.228] %GTPV1_END_USER_MSISDN GTPv1 End User MSISDN [NFv9 57701][IPFIX 35632.229] %GTPV1_END_USER_IMEI GTPv1 End User IMEI [NFv9 57702][IPFIX 35632.230] %GTPV1_APN_NAME GTPv1 APN Name [NFv9 57703][IPFIX 35632.231] %GTPV1_MCC GTPv1 Mobile Country Code [NFv9 57704][IPFIX 35632.232] %GTPV1_MNC GTPv1 Mobile Network Code [NFv9 57705][IPFIX 35632.233] %GTPV1_CELL_LAC GTPv1 Cell Location Area Code [NFv9 57706][IPFIX 35632.234] %GTPV1_CELL_CI GTPv1 Cell CI [NFv9 57707][IPFIX 35632.235] %GTPV1_SAC GTPv1 SAC
Plugin GTPv2 Signaling Protocol templates: [NFv9 57742][IPFIX 35632.270] %GTPV2_REQ_MSG_TYPE GTPv2 Request Msg Type [NFv9 57743][IPFIX 35632.271] %GTPV2_RSP_MSG_TYPE GTPv2 Response Msg Type [NFv9 57744][IPFIX 35632.272] %GTPV2_C2S_S1U_GTPU_TEID GTPv2 Client->Svr S1U GTPU TEID [NFv9 57745][IPFIX 35632.273] %GTPV2_C2S_S1U_GTPU_IP GTPv2 Client->Svr S1U GTPU IP [NFv9 57746][IPFIX 35632.274] %GTPV2_S2C_S1U_GTPU_TEID GTPv2 Srv->Client S1U GTPU TEID [NFv9 57747][IPFIX 35632.275] %GTPV2_S2C_S1U_GTPU_IP GTPv2 Srv->Client S1U GTPU IP [NFv9 57748][IPFIX 35632.276] %GTPV2_END_USER_IMSI GTPv2 End User IMSI [NFv9 57749][IPFIX 35632.277] %GTPV2_END_USER_MSISDN GTPv2 End User MSISDN [NFv9 57750][IPFIX 35632.278] %GTPV2_APN_NAME GTPv2 APN Name [NFv9 57751][IPFIX 35632.279] %GTPV2_MCC GTPv2 Mobile Country Code [NFv9 57752][IPFIX 35632.280] %GTPV2_MNC GTPv2 Mobile Network Code [NFv9 57753][IPFIX 35632.281] %GTPV2_CELL_TAC GTPv2 Tracking Area Code [NFv9 57754][IPFIX 35632.282] %GTPV2_SAC GTPv2 Cell Identifier
Plugin Radius Protocol templates: [NFv9 57712][IPFIX 35632.240] %RADIUS_REQ_MSG_TYPE RADIUS Request Msg Type [NFv9 57713][IPFIX 35632.241] %RADIUS_RSP_MSG_TYPE RADIUS Response Msg Type [NFv9 57714][IPFIX 35632.242] %RADIUS_USER_NAME RADIUS User Name (Access Only) [NFv9 57715][IPFIX 35632.243] %RADIUS_CALLING_STATION_ID RADIUS Calling Station Id [NFv9 57716][IPFIX 35632.244] %RADIUS_CALLED_STATION_ID RADIUS Called Station Id [NFv9 57717][IPFIX 35632.245] %RADIUS_NAS_IP_ADDR RADIUS NAS IP Address [NFv9 57718][IPFIX 35632.246] %RADIUS_NAS_IDENTIFIER RADIUS NAS Identifier [NFv9 57719][IPFIX 35632.247] %RADIUS_USER_IMSI RADIUS User IMSI (Extension) [NFv9 57720][IPFIX 35632.248] %RADIUS_USER_IMEI RADIUS User MSISDN (Extension) [NFv9 57721][IPFIX 35632.249] %RADIUS_FRAMED_IP_ADDR RADIUS Framed IP [NFv9 57722][IPFIX 35632.250] %RADIUS_ACCT_SESSION_ID RADIUS Accounting Session Name [NFv9 57723][IPFIX 35632.251] %RADIUS_ACCT_STATUS_TYPE RADIUS Accounting Status Type [NFv9 57724][IPFIX 35632.252] %RADIUS_ACCT_IN_OCTETS RADIUS Accounting Input Octets [NFv9 57725][IPFIX 35632.253] %RADIUS_ACCT_OUT_OCTETS RADIUS Accounting Output Octets [NFv9 57726][IPFIX 35632.254] %RADIUS_ACCT_IN_PKTS RADIUS Accounting Input Packets [NFv9 57727][IPFIX 35632.255] %RADIUS_ACCT_OUT_PKTS RADIUS Accounting Output Packets
and as well save traffic information on dump files using some command line options:
--gtpv1-dump-dir <dump dir> | Directory where GTPv1 logs will be dumped --gtpv1-exec-cmd <cmd> | Command executed whenever a directory has been dumped --gtpv2-dump-dir <dump dir> | Directory where GTPv2 logs will be dumped --gtpv2-exec-cmd <cmd> | Command executed whenever a directory has been dumped --radius-dump-dir <dump dir> | Directory where Radius logs will be dumped --radius-exec-cmd <cmd> | Command executed whenever a directory has been dumped
In essence nDPI, PF_RING and nProbe are now able to monitor multi-Gbit mobile traffic and automatically correlate GTP-C to GTP-U traffic in the probe using the microcloud without doing it on the collector as other tools do. The advantage is that as soon as a flow is exported, the collector immediately knows the mobile user that has generated the traffic not to mention that correlation implemented on the collector is costly in terms of computing resources. As the information in the microcloud is persistent, in the unlikely case of crash, nothing is lost as the user-to-GTP traffic correlation is maintained in the microcloud. This also applies in case mobile traffic grows and additional probes need to be started (also on different network locations that are still connected via IP to the microcloud): they automatically, since their startup, are able to correlate user-to-traffic.
To date, nProbe is used to permanently monitor the traffic of some country-wide mobile operators. If you are interested in testing it into your environment, you can download a ready-to-user nProbe binary package and have fun!