Studying the Gi interface

On the Gi interface the GRE protocol is commonly used for network layer tunneling. GRE is located over IP and it encapsulates the user IP packet. That packet needs to be extracted from GRE and passed into TAM. The GRE protocol itself does not carry any information needed by TAM.

L2TP/PPP may also be used to encapsulate user packets. L2TP is defined in RFC 2661[34**]. It is transported above IP/UDP using UDP port 1701. The version 2 of the L2TP protocol has a header resembling GRE. Although, L2TP defines both control and user traffic, TAM processes only the user traffic. L2TP is always followed by PPP [47**][48**].

By examining the protocol field of PPP, the protocol that follows PPP could be detected. PPP may contain the address and code fields before the protocol field. Their values are 0xff and 0x03 respectively. Furthermore, the protocol field may be compressed occupying 1 byte or uncompressed 2 bytes long. Based in IANA standardization, the IP protocol following PPP has a value of 0x0021.

The only L2TP data example was found in Trace6. The trace contained also GRE version 1[32] used to carry only PPP. Thus the protocol was im- plemented in TAM. The order that the protocols are examined is L2TP/PPP is analyzed and the outer header is skipped if it exists. Then GRE is analyzed and the outer header is skipped too if it exists. That is based on the observa- tion that is possible for L2TP to carry IP packets that contain the GRE pro-

tocol. For more information about L2TP and GRE please refer to Appendix D.

The status information produced by the status system implemented in TAM revealed interesting results:

Trace4:

The trace contained only RADIUS accounting and no RADIUS authentic- ation packets. The packets involved 47338 accounting start and 46777 ac- counting stop messages. Most of the messages contained the optional 3GPP IMSI field.

The most important thing though, is that for 12293 messages no entry could be found in TAM. That is because of the border effect and the presence of damaged files in the trace.

All RADIUS messages and identified data packets were transported over GRE tunnels explaining the large number of IP fragments (297206).

However, there existed other data packets outside the GRE tunneling functionality. A test was performed in order to determine if these packets could be identified by the information carried in RADIUS messages. The results were that none of the packets could be identified. Their presence re- mains a mystery. If we exclude the non GRE data the success rate climbs to 30%. Considering the border effect, the damaged trace files and the short trace duration the success rate is satisfactory.

In only 34 Accounting Request messages TAM could not extract the user information. The reason was that these messages had accounting type other than start and stop (the two RADIUS accounting types analyzed by TAM).

Trace5:

The trace contained only RADIUS accounting messages and no tunneling protocols. However, the trace is dominated by the Wireless Transaction Pro- tocol that is a layer of the Wireless Application Protocol (WAP). Although the success rate of the trace is high, WAP is not recognized by TAM.

Trace6:

The trace contained very few Accounting Request messages, 1108, trans- ferred as normal IP packets. All of them contained the user IMSI. However, they were able to identify only 1295 data packets.

The main reason was that most of the packets were encapsulated on L2TP/ PPP and/or GRE tunnels. None of these packets could be initially recognized by TAM. They consisted more than half of the total data packets on the trace. Trace6 was the most important reason that L2TP was implemented in TAM as is the only trace that carries the protocol. However, testing the res- ults of Trace6 after the L2TP implementation, showed zero improvement in the success rate. The RADIUS packets could only identify packets that were not carried via L2TP or GRE.

Finally, the trace was the only Gi trace that contained Diameter packets. The number of the packets was very low, only 20 packets, and carried no user identification information.

Trace7:

RADIUS access messages first appeared on this trace. They did not con- tain the user address (Framed-IP-Address) though.

Furthermore, from the 2212 Accounting Request messages, none could be processed correctly by TAM since they were truncated to 200 bytes and im- portant RADIUS elements were missing, e.g. the MSISDN of the user.

The success rate of the trace was as a result zero. Trace8:

The trace contained both RADIUS access and accounting messages. However, only the latter contained the user address.

The total number of Accounting Request start messages was 3849. The stop messages were similar in number but in 2434 of them the entry did not exist in TAM showing partially the amount of active RADIUS sessions25_.

The accounting messages contained 3GPP attributes but not the IMSI. As the trace contained no tunneling data the number of IP fragments is very low, less than 0.3 %.

The trace success rate is low mainly because of the very short trace dura- tion.

A general comment about the Gi traces and the RADIUS messages is that based on the studied traces RADIUS 3GPP attributes, like the IMSI, are in- cluded only in accounting messages. That is another reason why the analysis of RADIUS access messages is not performed in TAM.

25 _{The partial number of active RADIUS sessions could be observed if we consider the ses-}

sions that started, stopped or started and stopped during the capture. For the rest of the ses- sions that have started sometime before the capture and ended sometime after the capture no direct method exist in order to quantify them.