Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 33.204  Word version:  17.0.0

Top   Top   Up   Prev   Next
0…   4…   5…   A… 
4 Principles of TCAP user security  4.1 Overview  4.2 Network architecture 
...

 

4  Principles of TCAP user security  p. 7

4.1  Overview  p. 7

This technical specification defines mechanisms for protecting all TCAP user messages called TCAPsec. Another approach which could partially achieve the same goal as TCAPsec is the use of NDS/IP [6] at the network layer when IP is used as the transport protocol. However, whenever inter-working with networks using SS7-based transport is necessary, protection with TCAPsec shall be used.
The benefit for an operator applying TCAPsec will gradually increase when more interconnected operators also apply TCAPsec. TCAPsec can be used together with TCAP handshake solutions, however when using TCAPsec for MAP SMS transfers between two PLMNs, running TCAP handshake in addition does not add more security.
Before protection can be applied, Security Associations (SA) need to be established between the respective SS7-SEG. Security associations define, among other things, which keys and algorithms to use at the SS7-SEG. The necessary SAs between networks are negotiated between the respective network operators. The negotiated SA will be effective PLMN-wide and distributed to all SS7-SEGs. Each SS7-SEG contains policy information containing the protection mode that shall be applied. Protected TCAP user signalling traffic will, for routing purposes, be indistinguishable from unprotected traffic to all parties except for the sending and receiving entities.
Annex B includes detailed procedures on how secure TCAP user signalling is performed between two SS7-SEGs.
Up

4.2  Network architecture  p. 7

4.2.1  General  p. 7

TCAPsec can be applied between different types of SS7 networks:
  1. between two PLMN's.
  2. between a PLMN and an SS7-carrier.
  3. between two SS7-carriers.
The first case is considered in the end-to-end architecture (cf. clause 4.2.2). This architecture is applied in case the communicating PLMNs do not wish to trust intermediate SS7-networks.
In a hub-and-spoke architecture, a concatenation of multiple second and third cases may happen (cf. clause 4.2.3). Using this architecture is required if certain payload related services are performed by an SS7-carrier for whom the SS7-carrier is trusted by the PLMN.
Up

4.2.2  End-to-end architecture  p. 8

In a PLMN that employs SS7-SEGs all TCAP user signalling messages entering or leaving the PLMN have to transit an SS7-SEG which belongs to the PLMN and which performs the protection of outgoing messages and the protection checking and de-protection or blocking of incoming messages. SS7-SEG shall do Global Title Translation. For all unprotected messages from network elements inside one PLMN that are destined for another PLMN, the destination point is a SS7-SEG of the originating PLMN. After the messages are protected by a SS7-SEG of the originating PLMN, this SS7-SEG shall direct the message towards the destination NE (cf. Figure 4.2-1).
One or several SS7-SEGs may be employed within a PLMN.
An SS7-SEG may be co-located with any TCAP user NE or it may stand alone. However, for the purpose of this specification and without imposing any restrictions, it is assumed that the SS7-SEG is stand alone.
It is further assumed that the SS7-SEGs are located at the border of the PLMN i.e. incoming messages transit an SS7-SEG before they reach any other node within the PLMN, and outgoing messages transit an SS7-SEG immediately before reaching a node outside the PLMN.
Copy of original 3GPP image for 3GPP TS 33.204, Fig. 4.2-1: End-to-end SS7-Security Gateway Architecture
Figure 4.2-1: End-to-end SS7-Security Gateway Architecture
(⇒ copy of original 3GPP image)
Up

4.2.3  Hub-and-Spoke architecture  p. 8

Using a hub-and-spoke architecture for SS7SEGs is required in following cases
  1. The intermediate SS7-carrier has to perform TCAP user payload modification
    An example of such a service is steering of roaming. Another example is an SMS hubbing architecture where the HUB (i.e. the SS7 carrier) has to insert a virtual SMSC-address in the MAP message.
  2. The intermediate SS7-carrier needs to perfom protocol interworking.
    Examples are inter-standard SMS for roaming into CDMA, and a CAMEL Gateway.
Using a hub-and-spoke architecture for SS7SEGs may be used for following cases but can also be performed in the end-to-end architecture.
  1. The intermediate SS7-carrier performs message screening (e.g. SPAM control) and may have to drop messages.
    If the communicating PLMNs have agreed to use protection mode 1 then using the end-to-end architecture is preferred from a security point of view.
    If the communicating PLMNs have agreed to use protection mode 2 and both PLMNs find it acceptable to share the confidentiality key with the SS7 carrier then the end-to-end architecture can be used and is preferred from a security point of view. If confidentiality key sharing is not acceptable then the hub-and-spoke architecture is the only possible solution.
  2. The intermediate SS7-carrier performs advanced reporting.
    The same considerations as for case c apply.
Figure 4.2-2 is one example of such a hub-and-spoke architecture.
Copy of original 3GPP image for 3GPP TS 33.204, Fig. 4.2-2: Example of Hub-and-Spoke SS7-Security Gateway Architecture
Figure 4.2-2: Example of Hub-and-Spoke SS7-Security Gateway Architecture
(⇒ copy of original 3GPP image)
Up

Up   Top   ToC