Enhancements for the Gi interface

On the Gi interface TAM should detect the RADIUS messages that carry the APN and MSISDN (and if present the IMSI too) of the user and associate them to the user packets.

The Gi interface is not specified as well as the Gn. That is because the tar- get of the Gn interface is to transparently transfer user data and do not inter- fere with the actual protocols used in the user data. The Gi interface does not carry the user data transparently, thus it may have many different protocols and networks to connect to. The use of protocols in the Gi interface is oper- ator (carrier) dependent. However, the most common protocol used to carry the packet data is IP. And RADIUS is commonly used for authentication and accounting purposes.

Operators often use GRE on the Gi interface that is a tunneling protocol on top of IP. The format of the GRE header and additional information about the protocol is mentioned in Appendix D. TAM filters and drops the GRE protocol together with the outer IP header of the packets before processing takes place in the Gi interface. Another tunneling mechanism used is to tun- nel PPP frames via L2TP[7]. Since the PPP frames may carry IP packets, they should be analyzed in TAM. L2TP tunnels network traffic via IP/UDP using UDP port 1701. TAM ignores the L2TP protocol and the outer IP head- er and processes only the encapsulated IP packets.

The procedure to be performed by TAM on the Gi interface is relatively simpler than analyzing the GTP protocol. Only one Radius message should be detected and analyzed, and that is the accounting request14_{. The Account-}

ing Request contains all fields necessary to bind the APN and MSISDN to

user data. The binding is performed by using the IP address of the user car- ried in the RADIUS accounting messages and detecting the packets that use this IP address as a source or destination.

TAM detects the RADIUS Accounting protocol via the same mechanism used for the GTP case, port matching, as is shown below:

The RADIUS message identified by TAM is only the Accounting Request

message since the response does not carry important information. The Ac-

14 _{The Accounting Response message does not carry important information, it is rather a re-}

sponse to the request. Furthermore, the Radius Access messages used for authentication pur- poses do not carry the IP address of the user and, thus, are not useful in the user profiling pro- cess.

Detect a RADIUS packet

If Packet.UDP_Src_Port equals 1813 or Packet.UDP_Dst_Port equals 1813

Packet carries RADIUS Accounting Packet is classified as RADIUS Accounting

counting Status Type attribute of the RADIUS Accounting Request message controls the creation and deletion of state information in TAM. A value of 1 (start) creates a new linked list entry in TAM and a value of 2 (stop) deletes the relative entry, if it exists in TAM.

The period between the Accounting Request start to the Accounting Re-

quest stop is known as an Accounting or RADIUS session, similarly to the

PDP context in GTP. It is the period that the user data can be associated to the control information of the RADIUS messages.

Similarly to the Gn interface, a linked list in TAM maintains the state re- quired for the association. An item on the list contains the following fields:

Table 2: The linked list fields on the Gi interface. Framed IP Address the network address assigned to the user

Accounting session

ID The ID of the accounting session used to bind together the ing Request start and stop messages Account- MSISDN the user phone number. Named as Calling Station ID in the RADIUS

terminology

APN the APN is called Called Station ID in RADIUS

IMSI the IMSI of the user may be carried in the RADIUS messages as a 3GPP Vendor Specific attribute

RADIUS ID a value assigned locally by TAM to uniquely identify every detected Accounting Session

The Accounting Request start message creates a new list item and fills the

above fields. It then creates a new entry in the hash table to facilitate fast search for the MSISDN and APN in the user packets. The hash table oper- ates similarly to the hash table on the Gn interface.

The association of the MSISDN, APN and the IMSI if exists is done via the matching of the user IP address in the data packets.

The Accounting Request stop message locates the list entry via the ac- counting session ID and the user address and deletes it.

The queries on the linked list on the Gi interface include:

• the Framed-IP-Address, Accounting Session ID, MSISDN and APN ◦ in order to detect possible duplicate linked list entries on the Ac-

counting Request Start messages

• the Framed-IP-Address and the Accounting Session ID

◦ to find relative entries for the Accounting Request Stop messages one more query, used for the association of control traffic to data packets, is:

• the Framed-IP-Address

The use of a linked list on the Gi interface rather than some other data structure, considering that the processing required is simpler without the many queries that GTP uses, is because: i) it keeps the same structure in the

two interfaces, ii) it is easy to extend the list in case more state information, like support for RADIUS authentication, needs to be maintained and iii) serves as a location to store the data and use short entries and the fast search- ing abilities of a hash table to link to them.

The RADIUS protocol includes also RADIUS authentication messages. However, these messages cannot help identify user flows as they do not carry the Framed IP Address attribute that contains the network address of the end user. That is supported by all Gi traces presented below.

Furthermore, according to the specification of the Gi interface the authen- tication messages are used in order to grant access for the user. When the user is authenticated then an IP address is assigned to the user. As a result it is highly unlikely the RADIUS authentication messages to contain the Framed IP Address attribute.

The RADIUS accounting messages are sent after access is granted for the user and the user IP address becomes known. As a result the accounting mes- sages are the ones to be processed in order to associate control information to user traffic in the Gi interface.

Another reason to not analyze the RADIUS access messages is illustrated in Figure 6. As the figure shows, there is no RADIUS authentication mes- sage used to signal the end of the RADIUS session. As a result even when the session is terminated, the state information would remain in TAM assum- ing that it captures and analyzes the RADIUS access messages. The RADI- US accounting messages are used both in the beginning and the end of the RADIUS session, making them more appropriate for session tracking.

Figure 6: Sequence of messages in the Gn and Gi interfaces. Note that no RADIUS authentication messages are used in the termination of the user session.