ummary This chapter focused on the key SigTran protocols and their role in a next- generation architecture of voice products. The SigTran work grew from a desire to decompose a traditional circuit switch into specialized components. It focused on the following two areas: • A transport protocol that is suitable for meeting the requirements of carrying telecommunication protocols, especially SS7, over a packet network. • The creation of adaptation layers that support the primitives of SCN telephony signaling protocols. SCTP was developed as the new generic transport protocol. It provides p erformance and reliability benefits for telephony signaling transport over the UDP and TCP transport protocols. The common elements of the adaptation layers were introduced and described in some detail, as were the following key adaptation layers: • M3UA— Provides for the transport of MTP Level 3 user part signaling (for example, ISUP and SCCP). • SUA— Provides for the transport of SCCP user signaling (for example, TCAP). • M2UA— Provides for the transport of MTP Level 2 user signaling (for example, MTP Level 3). • M2PA— Provides a means of creating an IP SS7 link by replicating MTP Level 2 and supporting the MTP Level 2 primitive boundary to MTP Level 3. • IUA— Provides for the transport of Q.921 user signaling (for example, Q.931). In addition, two protocols related to SigTran were introduced: TALI and the early Cisco backhaul protocol stack. Finally, some examples of SS7 to SIP and H.323 interworking were provided to provide a context for how SigTran protocols can be used with other VoIP protocols. < Day Day Up > < Day Day Up > Chapter 15. SS7 Security and Monitoring Signaling System No. 7 (SS7) is a castle in terms of security, although the castle walls are increasingly coming under attack. The main forces acting on the protocol to wear down its defenses are market liberalization and ever-increasing convergence. When SS7 was designed and initially deployed, comparatively few telephone companies with well-defined network boundaries existed. That environment no longer exists because of market liberalization; there are more telephony providers than could have been imagined when SS7 was first drawn up. The convergence of SS7 with next generation architectures such as IP networks has created the need for additional security enforcement. SS7 has relied on an isolated signaling network for much of its' security and the interconnection with IP networks and interworking with other packet protocols changes this paradigm. The lack of security inherent in the SS7 protocol is likely to be increasingly exposed in line with communications convergence and with the ever-increasing number of operator interconnects. At present, traditional SS7 has no security mechanisms to ensure that a sender is who he says he is, nor is there cryptographic protection against alteration of messages. Securing traditional SS7 currently focuses on screening incoming traffic and monitoring for unusual traffic. This chapter examines each of these security measures. < Day Day Up > < Day Day Up > Traffic Screening This section provides a practical overview of SS7 traffic screening. Traffic screening is normally applied at Signal Transfer Points (STPs) because these are normally the gateways between operator networks. Network operators are responsible for ensuring the security of their own SS7 networks to defend against any unwarranted incoming traffic. At present, SS7 traffic can be altered, injected, or deleted after physical access to the signaling links is gained. STPs normally have extensive screening functionality. Typically, the screening rules are specified on a per-linkset basis. Usually the STP can support something in the range of a few thousand conditional statements that can be applied to each linkset. Screening usually adds only a couple milliseconds to cross STP transmission time. STP gateway screening is typically applied to provide access-control mechanisms to nonhome SS7 networks (interconnects). Figure 15-1 illustrates this concept. Figure 15-1. STPs May Be Used to Filter Incoming SS7 Messages Before an incoming Message Signal Unit (MSU) is accepted, it should pass a series of filtering rules that ensure conformance to the specified criteria. If an MSU does not pass the test, it should be discarded. This operation is known as message screening. Screening normally is applied only to the incoming internetwork SS7 MSUs. Screening procedures normally are not applied to outgoing or intranetwork MSUs. Internetwork MSUs are of high importance because they constitute the traffic coming in from other operators via interconnects. Screening is normally applied at the Message Transfer Part (MTP) 3 and Signaling Connection Control Part (SCCP) protocols layers. MTP screening is applied before any Global Title Translation (GTT). Normally there are pre-GTT and post-GTT SCCP screening rules. The following typical MTP basic screening rules can be combined to build more complex screening functionality: • Allow specified Originating Point Code (OPC) • Block specified OPC • Allow specified Destination Point Code (DPC) • Block specified DPC • Permitted Service Information Octet (SIO) values include priority values as per the Service Indicator (SI) subfield, network values as per the Network Indicator (NI) subfield, and the User Part values as per the Subservice field (SSF) • Allow certain MTP3 H0/H1 values (signaling network management messages) The following typical pre-GTT SCCP screening rules can be combined to build more complex screening functionality: • Calling Party Address (CgPA) parameters such as point code allowed, subsystem number allowed, SCCP message type allowed, routing indicator allowed, and translation type allowed The following typical post-GTT SCCP screening rules can be combined to build more complex screening functionality: • Called Party Address (CdPA) parameters such as point code allowed, subsystem number allowed, and SCCP management messages allowed The next sections look at the protocol issues you should keep in mind when p lanning to implement screening rules. S creenin g Considerations The following sections discuss areas of concern surrounding the various protocols in a core SS7 stack. In general, signaling related to the control and management of the whole network is somewhat more of a target for fraud than, say, signaling relating to one call only. MTP The lower levels of MTP (MTP1 and MTP2) are involved in the reliable transfer o f SUs on only a link-by-link basis, rather than on an end-to-end basis. Therefore, screening is not provided at these layers, and monitoring systems may take many measurements relating to MTP2 performance instead. MTP screening is provided for MTP3, because it provides the routing of MSUs through the SS7 network and as such, contains information related to the network topology, such as routing tables. The information relating to network topology can change dynamically by the network management functions of MTP3. Therefore, MTP3 network management messages need to be both screened and monitored, because they can access and modify the network's routing information. SCCP As with MTP3, SCCP carries messages arriving from both Level 4 and self- generated SCCP network management messages. SCCP management informs other nodes of application status, such as whether a particular application is working. < Day Day Up > < Day Day Up > MTP3: Management Messages These messages are generated by the MTP3 level to maintain the signaling service and to restore normal signaling conditions in the case of failure, either in signaling links or signaling points. MTP3 is explained in Chapter 7 , "Message Transfer Part 3 (MTP3)." MTP3 messages carrying relevant information that can affect the network if abused and can be split into two categories: • Messages communicating unavailability (such as COO, COA, ECO, ECA, TFP, TFR, and TFC) • Messages communicating availability (such as CBD and TFA) A higher degree of risk is associated with the first category, because they diminish available resources. As such, care should be given to the screening of such messages. For example, the Transfer Restricted (TFR) message is involved in routing reconfiguration and traffic diversion. Therefore, a degree of risk is involved in receiving or sending this message if it is propagated unintentionally or with malicious intent. Unintentional transmission is likely to be caused by software or configuration errors. Malicious intent is because someone with physical access (an insider) sends the message intentionally with the use of a protocol analyzer, for example. Table 15-1 lists the main MTP3 messages that should be screened. Table 15-1. MTP3 Messages to Be Screened Message Parameter Reason for Screening MSU (in case of an STP) OPC Verifies that the originating node is known (is present in the routing tables). This provides a degree of protection against unauthorized access to the network. DPC Verifies that the message is destined for a valid node (a node to which the originating point is allowed to route). Changeover, Changeback, and OPC Verifies that the message is received from an adjacent node that is allowed to send this Emergency Changeover message type. DPC Verifies that the message is destined for itself. Transfer Prohibited Transfer Restricted OPC Verifies that the message is received from a node allowed to send these types of messages. Management Inhibiting OPC Verifies that the message is received from an adjacent node allowed to send this type of message. Transfer Control OPC Verifies that the message is received from a node allowed to send this type of message. The operator should choose the allowed node list according to their network topology and routing. DPC Verifies that the message is destined for a node to which the originating node can route traffic. It should be verified that all messages' MSUs are received on a valid linkset—that is, the originating point is allowed to use that particular linkset. The primary MTP3 parameters that should be screened are the originating and destination point code. These are described next. Originating Point Code This parameter is the address of the originating node and forms part of the routing label. The OPC should be verified, as well as the rights that the node sending the message can route via the STP. This can be done by checking that the node is p resent in routing tables. Note that no mechanisms prove that the node is the one claimed. Instead, the OPC simply acts as a check that the node at least claims to be the correct node. D estination Point Code This parameter is the address of the destination node, and it forms part of the routing label. The DPC should be analyzed to verify the following: • MSUs coming from an external node are addressed to a node inside your own network (to keep the STP from being used as a transit node of unwarranted traffic). • MTP3 management messages coming from an external node are addressed only to the STP and not to a node inside your own network. (Management messages should involve interconnecting only nodes at the interface with other networks, not other parts of the signaling network itself.) . how SigTran protocols can be used with other VoIP protocols. < Day Day Up > < Day Day Up > Chapter 15. SS7 Security and Monitoring Signaling System No. 7 (SS7) is a castle. signaling service and to restore normal signaling conditions in the case of failure, either in signaling links or signaling points. MTP3 is explained in Chapter 7 , "Message Transfer Part. Transfer Part (MTP) 3 and Signaling Connection Control Part (SCCP) protocols layers. MTP screening is applied before any Global Title Translation (GTT). Normally there are pre-GTT and post-GTT