Signaling System No.7 Protocol Architecture And Sevices part 59 potx

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.. DPC Verifies

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 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 present 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

Destination 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.)

SCCP

This section describes typical SCCP screening considerations SCCP is explained

in Chapter 9, "Signaling Connection Control Part (SCCP)."

SCCP User Messages

These messages come from above SCCP via Transaction Capabilities Application Part (TCAP) and are related to the applications running on TCAP (for example, intelligent network services, mobility services, and value-added services) These messages typically use GTT functionality Some STPs offer the functionality to screen so that only permitted nodes may request translations, the translations

themselves are valid, and the translations themselves are permitted

Management Messages

Management messages are generated by the SCCP level to maintain network

performance by rerouting or throttling traffic in the event of failure or congestion

The messages that can reroute the traffic constitute the means by which the

integrity of the signaling network at SCCP level can be penetrated and endangered These messages are discussed in the following sections

Subsystem Prohibited (SSP)

A Subsystem Prohibited (SSP) message is sent to concerned destinations to inform SCCP Management (SCMG) at those destinations of the failure of a subsystem The receiving end of an SSP message updates its translation tables; therefore, traffic could be rerouted to a backup subsystem if available If not, an SCCP user might no longer be able to offer a particular service It is imperative that

verification takes place to ensure that this message is received from a permitted node The only means of verification is to check the OPC from which the message

is received

Subsystem Allowed (SSA)

A Subsystem Allowed (SSA) message is sent to concerned destinations to inform them that a subsystem that was formerly prohibited is now allowed or that an

SCCP that was formerly unavailable is now available The node receiving the SSA, therefore, updates its translation tables Because the message indicates availability,

less risk is associated with it

Subsystem Status Test (SST)

The Subsystem Status Test (SST) message is sent to verify the status of a

subsystem that is marked prohibited or the status of an SCCP marked unavailable The receiving node checks the status of the named subsystem If the subsystem is allowed, an SSA message is sent in response If the subsystem is prohibited, no reply is sent

The originating node should be verified by checking the OPC to make sure that it has the necessary rights

Parameters

To provide screening, you do not need to read every field comprising a message Instead, you read only the fields (parameters) that can cause a security threat The parameters that contain the message's origin and destination and those used in GTT have particular security importance

Table 15-2 SCCP Messages to Be Screened

Message Parameter Reason for Screening

UDT and

XUDT

Calling Party Address

Verifies that the message is received from a specified remote subsystem (such as a specified combination of SSN+SPC)

Called Party

Address

For routing on SSN, verifies that the message is destined for a local subsystem

For routing on GT, verifies that the message uses

a valid translation table (such as a table allowed for the origin)

Results of the

translation

Verifies that the new values of DPC and SSN match values allowed by the originating node SSP and

SSA

Calling Party Address

Verifies that the message is received from a specified remote subsystem (such as a specified combination of SSN+SPC)

Called Party

Address

Verifies that the message is destined for the management of SCCP (SSN = 1)

Affected point

code

Verifies that the affected node is inside the originating network

subsystem number

Verifies that the affected subsystem is known

Address

Verifies that the message is received from a valid remote subsystem (such as a valid SSN+SPC)

Called Party

Address

Verifies that the message is destined for the management of SCCP (SSN=1)

Traffic Monitoring

Monitoring signaling traffic is the simplest method of revealing accidental

(because of misconfiguration, for example) or intentional abuse of the SS7

network Because signaling is the nervous system of the telecommunications

network, it should be clear that if the SS7 network goes down, so does the entire telecommunications network it supports Intentional or other acts that cause

impairments in signaling performance can cause all kinds of critical failure

scenarios, including incorrect billing, lack of cellular roaming functionality, failure

of Short Messaging Service (SMS) transfer, unexpected cutoff during calls, poor line quality, poor cellular handovers, nonrecognition of prepay credits, multiple tries to set up calls, ghost calls, and the inability to contact other subscribers on certain other networks

The SS7 network's quality of service (QoS) directly relates to the lack of QoS to subscribers Thus, it is vital to monitor the SS7 network sufficiently to ensure that impairments, whatever their origin, are realized as soon as possible Monitoring is specified in ITU-T recommendation Q.752 [71] Further useful ITU-T references are provided in Q.753 [72]

Monitoring entails measuring the traffic in terms of messages, octets, or more detailed information, such as counts of certain message types or GTTs requested Monitoring can be applied to any set of links, but it is considered essential at links that interconnect with other networks (for example, those crossing an STP or

certain switches) In fact, monitoring systems tend to connect with a multiple

number of links throughout the SS7 network, in effect, producing an overlay

monitoring network The monitoring points simply consist of line cards that are tapped onto the links to unobtrusively gather and process real-time data The

information obtained from the multiple points is then aggregated and analyzed at a central point (common computing platform) The processing platform is likely to vary in power and complexity, depending on the scale of the purchase Higher-end systems provide intelligent fraud and security monitoring, and lower-end systems simply provide statistics and alerts when performance thresholds are crossed

The values measured are compared to a predetermined threshold for "regular

traffic." When a value exceeds the predetermined threshold, an alarm normally is generated, and a notification might be sent to maintenance personnel In this way, SS7 network monitoring helps the network operator detect security breaches Some examples of high-level measurements are Answer Seizure Ratio (ASR), Network Efficiency Ratio (NER), and Number of Short Calls (NOSK) ASR is normal call

clearing divided by all other scenarios NER is normal call clearing, plus busy, divided by all other call-clearing scenarios NOSK is simply the number of calls with a hold time less than a prespecified value To reflect a high QoS, a high NER and ASR are desired as well as a low NOSK

SS7 monitoring systems are changing to reflect the convergence taking place Many can show the portions of the call connected via SS7, and other portions of the call connected via other means, such as Session Initiation Protocol (SIP)

As convergence takes hold, a call has the possibility of traversing multiple

protocols, such as SIGTRAN, SIP, H.323, TALI, MGCP, MEGACO, and SCTP Monitoring systems that support converged environments allow the operator to perform a call trace that captures the entire call SIGTRAN is explained in Chapter

14, " SS7 in the Converged World."

It should also be mentioned that monitoring the signaling network has other

advantages in addition to being a tool to tighten up network security:

• Customer satisfaction— Historically, information was collected at the

switches, and operators tended to rely on subscriber complaints to know that something was wrong QoS can be measured in real time via statistics such

as, call completion rates, transaction success rates, database transaction analysis, telemarketing call completion (toll free, for example), and

customer-specific performance analysis The captured data is stored in a central database and, therefore, can be used for later evaluation—for

example, by network planning

• Billing verification

• Business-related opportunities— Data mining for marketing data, producing statistics such as how many calls are placed to and from competitors

• Enforcing interconnect agreements— Ensure correct revenue returns and validate revenue claims from other operators Reciprocal compensation is steeply rising in complexity

Presently, the most common security breach relates to fraud The monitoring

system may be connected to a fraud detection application Customer profiles are created based on the subscriber's typical calling patterns and can detect roaming fraud, two calls from the "same" mobile (for example, SIM cloning), subscription fraud, and so on The real-time nature of monitoring allows active suspicious calls

to be released before additional operator revenue is lost

Monitoring systems should be capable of most of the measurements defined in

ITU-T recommendation Q.752 [71] The rest of this section lists the bulk of these measurements for each level in the SS7 protocol stack

Q.752 Monitoring Measurements

The number of measurements defined in Recommendation Q.752 [71] is very large They are presented in the following sections Note that most of the

measurements are not obligatory, and that many are not permanent but are on activation only after crossing a predefined threshold The obligatory measurements form the minimum set that should be used on the international network

MTP: Link Failures

Measurements:

• Abnormal Forward Indicator Bit Received (FIBR)/Backward Sequence Number Received (BSNR)

• Excessive delay of acknowledgment

• Excessive error rate

• Excessive duration of congestion

• Signaling link restoration

MTP: Surveillance

Measurements:

• Local automatic changeover

• Local automatic changeback

• Start of remote processor outage

• Stop of remote processor outage

• SL congestion indications

• Number of congestion events resulting in loss of MSUs

• Start of linkset failure

• Stop of linkset failure

• Initiation of Broadcast TFP because of failure of measured linkset

• Initiation of Broadcast TFA for recovery of measured linkset

• Start of unavailability for a routeset to a given destination

• Stop of unavailability for a routeset to a given destination

• Adjacent signaling point inaccessible

• Stop of adjacent signaling point inaccessible

• Start and end of local inhibition

• Start and end of remote inhibition

Additional measurement may be provided to the user for determining the network's integrity

Measurements:

• Local management inhibit

• Local management uninhibit

• Duration of local busy

• Number of SIF and SIO octets received

• Duration of adjacent signaling point inaccessible

MTP: Detection of Routing and Distribution Table Errors

Measurements

• Duration of unavailability of signaling linkset

• Start of linkset failure

• Stop of linkset failure

• Initiation of Broadcast TFP because of failure of measured linkset

• Initiation of Broadcast TFA for recovery of measured linkset

• Unavailability of route set to a given destination or set of destinations

• Duration of unavailability in measurement

• Start of unavailability in measurement

• Stop of unavailability in measurement

• Adjacent SP inaccessible

• Duration of adjacent SP inaccessible

• Stop of adjacent SP inaccessible

• Number of MSUs discarded because of a routing data error

• User Part Unavailable MSUs transmitted and received

MTP: Detection of Increases in Link SU Error Rates

Measurements:

• Number of SIF and SIO octets transmitted

• Number of SIF and SIO octets received

• Number of SUs in error (monitors incoming performance)

• Number of negative acknowledgments (NACKS) received (monitors