What is TCAP?
Let’s begin with a classic textbook definition of “Transaction Capabilities”. Transaction Capabilities (TC) provide functions and protocols to a large variety of applications distributed over switches and specialized centers in telecommunication networks (e.g. databases).
OK, so what does that really mean and what is TCAP? Transaction Capabilities Application Part (TCAP) is the layer of the SS7 protocol that carries application data to be exchanged between nodes. Basically, it means that TCAP offloads the applications from having to concern themselves with mundane structures and dialogues. TCAP defines the overall structure that the application will have to conform to, but TCAP does not concern itself with what information is being passed. That’s the job of the application. This could be a wireline application like Core INAP (CIN) or a mobile telecom application like GSM MAP. So TCAP is a set of communication capabilities that provide an interface between applications and a network layer service. To date, only Signaling System No. 7 (SS7) Message Transfer Part (MTP) plus Signalling Connection Control Part (SCCP) have been considered as network layer service providers. However, any standard OSI Network Layer might be used in place of the MTP plus SCCP, provided that the requirements of the applications supported by TC (e.g. service and performance requirements) can be met. By the way, for historical reasons, the term “TC” and “TCAP” are used interchangeably. For this article, we will stick with “TCAP”.
The main purpose of TCAP then is to provide the upper applications with generalized services to send information (applications) over the network using dialogues and non-circuit related signaling. Before TCAP was developed, each application implemented its own dialogue handling separately. Therefore, a standardized dialogue handling function was created to minimize the need for creating new services and protocols to handle dialogues. TCAP provides the services to transfer information between nodes, independent of applications. It is defined as an end-to-end protocol, which implies that the protocol will not process the message other than in the sending and receiving end nodes.
From SCCP’s point of view, TCAP is merely another variable length parameter. So TCAP sits between SCCP and the application. A typical structure drawing of the SS7 protocol is shown here:
The overall objective then of TCAP is to provide the means for the transfer of information between nodes and to provide generic services to applications while being independent of any of these. Some of the services that TCAP provides to the application include:
- A means to package application parameters
- Allowing the application to convey multiple tasks within a single message (transaction)
- Providing a way to uniquely identify each message using transaction management
- Allowing applications to carry on dialogues
Within TCAP there are up to three parts or portions. They are:
- Transaction Portion – it provides the ability to associate multiple operations with a single logical transaction between nodes.
- Dialogue Portion – used to interpret component information and software versions.
- Component Portion – this allows the application the ability to define different operations and to exchange parameters.
TCAP is defined by the ITU in Q.771 through Q.775.
Is TCAP Safe?
It is fairly well known that there are the more “interesting” layers in the SS7 protocol that carry useful parameters like network identities, status, state and location information. So, since TCAP itself does not carry any of that type of information, is it a relatively “safe” layer? In a word, the answer is “no”. TCAP suffers from the same lack of any built-in security as all of the layers of the SS7 protocol. Though it might not contain user-specific information like GSM MAP, nor originating and terminating information like SCCP, a lot of damage can be done by a nefarious intruder with knowledge of TCAP. Plus, knowing something at this layer provides that intruder with a bigger piece of the overall events and network behavior in order to do damage. Often times injecting a message into the network will produce an error message containing useful information. TCAP carries information about transaction identifiers, which are kept open during the lifetime of a transaction and can be useful for keeping a transaction open. TCAP also carries information about the application context and version numbers. Using information gathered from these types of scans the intruder can perform other types of attacks like denial of service, impersonation of network elements and fraud.
TCAPsec
There are defined mechanisms for protecting all TCAP user messages called TCAP Security (TCAPsec). It is a set of enhancements and extensions designed for security protection for the TCAP protocol. It ensures that the original data has not been altered (data integrity) and it provides confirmation that the source of the data is as claimed (data origin authentication). There are other ancillary uses, but those two are the primary ones. Though TCAP as a protocol is defined by the ITU-T (Q.771 through Q.775), TCAPsec is defined by the Third Generation Partnership Project (3GPP) in two specifications. They are:
- 3GPP TS 29.204 – SS7 Security Gateway Architecture & Protocols
- 3GPP TS 33.204 – TCAP User Security
TCAPsec can, of course, be applied to different types of networks as shown here:
The top example is considered an end-to-end architecture. This would be the case where the two PLMNs do not wish to use a third-party provider of signalling services.
The TCAP message is sent as a Unidirectional Message Type without a Dialogue Portion. It uses Operation Code (OpCode) 90 and contains three parameters as shown.
The details can be found in 3GPP TS 29.234. So, basically you are taking an SS7 UDT or XUDT message and packaging it up as a one-way TCAP unidirectional message. The original SCCP and TCAP values are placed, along with a Protected Payload as parameters in a SecureTransport TCAP unidirectional operation using opcode 90.
Though quite a simple scheme, the network details get a bit complex. First of all it requires new components to be augmented to the network. These components are an SS7 Security Gateway (SEG), a Security Policy Database (SPD) and a Security Association Database (SAD). An SEG performs the protection of outbound and inbound messages. It is the duty of the SEG to secure the TCAP transactions with help from the SPD. In addition, before protection can be applied there needs to be a Security Association (SA) established between the two SEGs.
The call flow steps for a TCAPsec in an SMS message flow are:
- An inter-PLMN TCAP signalling message is sent from an SMSC to the Signalling Gateway (SEG)
- The SEG checks the security policy from the Security Policy Database (SPD)
- The SEG also asks for the security parameters from the Security Association Database (SAD)
- Based on the policy and security parameters received, the SEG constructs the TCAPsec message
- The TCAPsec message is sent inter-PLMN to the receiving network’s SEG
- The receiving SEG checks the security policy from its SPD
- The receiving SEG also checks the security parameters from its SAD
- Based on the policy and security parameters received, the SEG checks the authenticity and integrity of the message. If needed, it “decrypts” the message
- The message is then sent to the recipient.
The call flow looks like this:
As you can see, this needs a lot of interworking between operators and all operators need to deploy TCAPsec for it to be truly effective.
TCAP Handshake
The idea behind the TCAP handshake is to force the originator to establish a dialogue before sending any kind of SM information. It acts much like the SCCP connection-oriented Connection Request and Connection Confirm messages. This is done by requiring the originator to first send an empty TC Begin request message to the recipient and having the recipient send a TC Continue back, thus having an open transaction. It is only after this dialogue initiation that the sending of the message can begin. These first two messages in effect are used for authentication.
Establishing this dialogue guarantees that the originator is using the correct address. Therefore, this should counteract the fraud of spoofing the originating address. The TCAP handshake is a fairly simple procedure to implement, since all the required functionalities exist in the current MAP and TCAP implementations.
The call flow for a MTForwardSM is shown here:
Although this appears to be a good solution, there are still a few problems that should be considered. The most obvious is that the TCAP handshake effectively increases the traffic in the network with the initial dialogue setup. Also, the protection the TCAP handshake offers is severely limited as it is designed only to prevent the specific fraud scenario of the MTForwardSM.
Given the simplicity of standardizing this solution, it is a good quick alternative for limited protection. However, with the problems mentioned above, TCAP handshake can only be at best a temporary solution until a better and more comprehensive solution is implemented to replace it like a comprehensive firewall that covers all of the layers of the protocol.
Categorised in: Blog