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 p rotocol verification, whereas compatibility testing is pe r formed against an online implementation and is used to verify the proper interworking of two or more p rotocol 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 p roduce 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 p resented with the message names according to protocol level, along with p arameters (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 p art 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 p lace, 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 p rove that their equipment is functioning correctly. N OTE 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 p rotocols, 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 p urpose 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 p rocess 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. N OTE N orth 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 ].  . Q .78 1 [ 87] covers MTP2 [50] • Q .78 2 [88] covers MTP3 [51] • Q .78 3 [89] covers TUP [64] • Q .78 4.1 [90] covers ISUP [75 78 , 80–81] • Q .78 5 [91] covers ISUP Supplementary Services [69] • Q .78 6. ITU-T specifies ISUP in recommendations Q .76 1–Q .76 4 [75 78 , 80]. The British Standards Institute (BSI) specify the UK nationalized version in PNO-ISC #0 07 [41 ]. If we were to test UK ISUP, we. tests 7. 3.1 through 7. 3.6 involve testing multirate connection types and can therefore be removed. • In relation to exceptions to Q .76 2 (ISUP general functions and signals), no UK-specific signaling