Summary SS7 was designed without integral security in mind. Its design is based on the use of dedicated physical facilities, making it difficult to compromise externally. In addition, at the time of design, fewer network operators existed
AMBIENT/
Chủ đề:
Nội dung Text: Signaling System No.7 Protocol Architecture And Sevices part 60
- Summary
SS7 was designed without integral security in mind. Its design is based on the use
of dedicated physical facilities, making it difficult to compromise externally. In
addition, at the time of design, fewer network operators existed, and the number of
interconnections was limited. With the increasing convergence in communications,
SS7 is no longer as isolated as it once was. To minimize the risks, screening may
be implemented and monitoring systems put in place. Screening lets you establish
rules governing whether to receive SS7 packets based on sender, destination,
service requested, and so on. Monitoring systems allow operators to diagnose and
resolve network failures, whether because of security lapses or otherwise.
< Day Day Up >
< Day Day Up >
Chapter 16. SS7 Testing
When a new implementation of C7 is introduced into a network, it must be
conformance tested against the appropriate standard to ensure that it functions
correctly. This is known as validation testing. Validation testing is performed
before the implementation is put into a live network.
After validation testing has been successfully completed, the implementation can
be deployed into the live network, where more testing will be performed. Testing
at this stage is known as compatibility testing. Compatibility testing ensures that
the implementation can interwork properly with the other signaling points that are
already in the network; it might also be referred to as interoperability testing. The
validation phase is performed against an offline implementation and is used for
protocol verification, whereas compatibility testing is performed against an online
implementation and is used to verify the proper interworking of two or more
protocol implementations.
The ITU-T has produced framework test specifications covering both validation
and compatibility for MTP2, MTP3, TUP, ISUP, ISUP Supplementary Services,
SCCP, and TCAP. The test specifications are contained in Recommendations
Q.781 to Q.787, respectively. While all tests are validation tests, a subset is also
marked as compatibility tests:
• Q.781 [87] covers MTP2 [50]
• Q.782 [88] covers MTP3 [51]
- • Q.783 [89] covers TUP [64]
• Q.784.1 [90] covers ISUP [75–78, 80–81]
• Q.785 [91] covers ISUP Supplementary Services [69]
• Q.786 [92] covers SCCP [58–63]
• Q.787 [93] covers TCAP [82–86]
Test Specifications for SIGTRAN (see Chapter 14, "SS7 in the Converged World")
are just becoming available at the time of this writing. The following are available
as drafts from the IETF:
• MTP2— User Peer-to-Peer Adaptation Layer (M2PA) Test Specification
• MTP2— User Adaptation Layer (M2UA) Test Specification
• MTP3— User Adaptation Layer (M3UA) Test Specification
A prerequisite for testing a given protocol layer is that the underlying layers have
been implemented correctly; that is, they have already passed validation and
compatibility testing. The tests intend to test the given protocol's key functionality
under normal and abnormal conditions; testing all work under all abnormal
conditions is impossible and impractical because of the nearly endless number of
tests that would be required.
The tests do not have to be performed sequentially; however, on the whole it is
generally more convenient to follow the test list in order. For some parts of the test
specification it might be easier to order by pre-test conditions because the end of a
test might be the pre-test condition of another test.
The chapter begins with an overview of the types of equipment that are available
for SS7 testing and discusses how to use the appropriate ITU-T test specification to
produce the required test specification. The rest of the chapter provides examples
with full explanations for common tests (as specified by the ITU-T) for validation
and compatibility of MTP2 to show the breadth of testing against a particular layer.
Finally, a few examples for MTP3, ISUP, Supplementary Services, and TCAP are
shown.
< Day Day Up >
< Day Day Up >
- Test Equipment
SS7 testing equipment can be used for a several purposes, including the following:
• System and conformance tests
• Functional testing from development to operation
• Integration/testing of new products
• Network entity emulation, such as Mobile Switching Center (MSC)
• Monitoring networks for error detection and analysis in the field
• Functional testing to reproduce error scenarios
The functionality of SS7 test equipment can be split into three categories:
monitoring, simulation, and emulation. Test equipment tends to come as monitor
only, with monitor and simulation, or with all three broad features of monitoring,
simulation, and emulation.
Monitoring entails the decoding and filtering of SS7 traffic, which results in a
determined subset being presented to the user in a readable format. The user is
presented with the message names according to protocol level, along with
parameters (further nesting might be present) and values. Monitoring can be
considered akin to a "record button" that can display the traffic afterwards.
Simulation is the ability to generate desired traffic. For example traffic already
caught using the monitoring function could be "played back" using the simulation
function. Often when an SS7 implementation—be it a national ISUP or another
part of the stack, such as a national INAP—is written following the appropriate
specification(s), it tends to be problematic. This usually arises from undocumented
implementation issues and specification ambiguity, including differing developer
interpretations. If you can obtain traffic of the protocol you are implementing,
captured from the live network via a tester's monitor functionality, you can use
simulation functionality to test your implementation against real network traffic.
This can save a lot of time when the product is connected to the live network for
compatibility testing.
Creating test traffic in this fashion is both faster and more accurate than coding test
traffic by hand entering hex. Simulation can be considered analogous to a "play
button."
Emulation can be the most advanced area of functionality. It gives the test
instrument the ability to pretend that it is another network entity—such as a
- signaling gateway (SG) or a mobile switching center (MSC). For example, if you
wish to perform conformance and interoperability testing of a Base Station
Controller (BSC) and a Base Transceiver Station (BTS) but the MSC is not in
place, you would ordinarily be stuck until the MSC was in place. However, with
emulation functionality you can substitute a tester for the missing MSC. The
instrument works like a fully compliant and functioning MSC and interacts with
the network and even imitates erroneous behavior, if desired. Before installation of
the real MSC begins, a set of acceptance test cases could be agreed upon with the
vendor and you should be armed with the knowledge that the BTS and BSC are
operating correctly. The responsibility spotlight is put onto the MSC vendor to
prove that their equipment is functioning correctly.
NOTE
Some analyzers that do not have the emulation function call the simulation
function by the name of "emulation." Be aware of this when considering what test
equipment is required for a particular application.
The modern trend in test equipment is to provide it in a portable form, with
multiprotocol capability. These test instruments not only work with the SS7 set of
protocols, but also with other established and emerging protocols, such as those
being used in GSM/PCS, GPRS, UMTS, cdma2000, and VoIP networks. For
example, a current product could offer monitoring, simulation, and emulation of
M3UA and SCTP (SIGTRAN), emulation of IPv6, a conformance test suite for
AAL2 Layer 3, a conformance test suite for MTP3b (Q.2210), monitoring and
simulation of IU UP (TS25.415), monitoring and simulation of RANAP
(TS25.413), in addition to providing monitoring, and simulation and emulation of
C7 protocols in a single package aimed at UMTS operators.
A fundamental yet often overlooked point is ensuring that the instrument can
support all the physical interface connections that might be required—let alone
issues of protocol support. For example, to fully test a UMTS network, the
following physical interface connections might be required:
• 2x E1 ATM
• 2x OC-3 ATM
• 2x E1
• 1x Fast Ethernet
- When you are satisfied that the instrument can meet the requirements of the
network(s) in which it is to operate at the physical level, work up the stack to
ensure that it supports all appropriate protocols. The instrument should also able to
evolve along with the standards it supports so it does not quickly become obsolete.
< Day Day Up >
< Day Day Up >
- Test Specification Creation
The test specifications produced by the ITU-T are unlikely to be run exactly as is.
Remember that the ITU-T C7 specifications are tailored to each country's needs—
the SS7 specifications provide national options and national coding space for the
purpose of nationalization. For additional details, see Chapter 2, "Standards."
The ITU-T test specification must be modified to reflect the national specification
against which it is to be tested. If we use UK ISUP as an example, the ITU-T
specifies ISUP in recommendations Q.761–Q.764 [75–78, 80]. The British
Standards Institute (BSI) specify the UK nationalized version in PNO-ISC #007
[41]. If we were to test UK ISUP, we would have to modify the ITU-T ISUP test
specification [90] to reflect UK ISUP [41]. This is not a daunting task. Remember
that national SS7 specifications are simply exception documents against ITU-T
recommendations that, in addition, state what national messages and parameters
have been selected for use, and what additional messages, parameters, and values
have been added (if any) into the coding space that the ITU-T set aside for the
process of nationalization. Where regional specifications exist, the national
specifications are, instead, likely to be exception documents against the regional
specifications. For example, UK ISUP is an exception document against the ETSI
specifications. But the regional specifications themselves are exception documents
(plus clarifications) against the ITU-T recommendations.
NOTE
North America, Japan, and China use regional specifications that do not adhere to
the ITU-T recommendation framework.
A copy of the tests laid out by the ITU-T ISUP test specification should be taken as
the basis for producing a UK ISUP test specification. It should then be modified
largely in terms of deleting the tests that are not required and adding some
additional tests; the national specification is unlikely to have selected all messages
offered by the ITU-T recommendation and, in addition, might have coded some
extra messages and parameters. This process is simply one of pulling the ITU-T
ISUP specification in line with the national variant.
Following are some example modifications:
- • In relation to exceptions to Q.761 (ISUP functional description), Table 1.1 in
UK ISUP [41] states that the UK has elected not to use multirate connection
types (that is 128, 384, 1536 and 1920Kbps bearer rates, which are achieved
by stacking up a number of 64 Kbps circuits). The six ISUP tests 7.3.1
through 7.3.6 involve testing multirate connection types and can therefore be
removed.
• In relation to exceptions to Q.762 (ISUP general functions and signals), no
UK-specific signaling messages have been defined; therefore, no new tests
are required to check the validation and interoperability of new messages.
But 11 UK-specific signaling parameters have been defined—for example,
National Forward Call Indicators (UK-specific information sent in the
forward direction relating to characteristics of the call). Therefore, up to 11
new tests should be created to ensure that these parameters are being
handled correctly.
• In relation to exceptions to Q.763 (formats and codes), the UK has elected
not to use the following message types: Forward Transfer (FOT), Continuity
(COT), and Continuity Check Request (CCR). FOT is tested in tests 6.4.1
through 6.4.4 [90], COT in tests 6.1.1 through 6.1.5 [90] and CCR in tests
1.4.1 through 1.4.5 [90]. These fourteen tests can therefore be removed.
A national test specification might be available; if so, it can be obtained from the
national incumbent or the national standards body. But it is still recommended that
one is self-produced because it familiarizes the person(s) performing the testing
with the tests and the national variant. In addition, the protocol test equipment
manufacturer is likely to be able to provide Q.78x conformance testing scripts—
that is, the tests that are configured almost ready to run. However, it should be
clear that these must also be brought into line with the national specification; this
can effectively be done in parallel with the test-specification production.
When the relevant ITU-T test specification and protocol tester Q.78x scripts (if
available) have been "nationalized," the next and final stage is to modify them to
reflect the actual solution/product under test, thereby producing a product/solution
specific C7 test specification. For example, if we were testing a method of
terminating ISP traffic, then the signaling portion of that solution is only going to
receive calls (terminate incoming ISP traffic); therefore, none of the tests that
necessitate any forward setup messages are required. This means that many of the
tests should be removed, such as all those tests that expect the device under test
(DUT) to generate an ISUP Initial Address Message (IAM)—for example, tests
2.3.x [90].
Thêm vào BST
Báo xấu
Download
Vui lòng tải xuống để xem tài liệu đầy đủ
