TR 33.926 [4], clause Y.2.4.1, SMSF control data and user data protection on SGd Diameter Interface

Protection data and information on SGd

TS 33.501 [3], clause 9.5, TS 33.210 [10], clause 6.2, TS 33.310 [11], clause 6.1.3a.

TS 33.501 [3] mentions that protection of Diameter interface shall be supported according to NDS/IP as specified in TS 33.210 [10], unless security is provided by other means e.g. physical security. For authentication between SMSF and Diameter application node over diameter interface, mutual authentication based on client and server certificates is performed, if using TLS. Certificate based authentication follows the profiles given in TS 33.210 [10] clause 6.2, and TS 33.310 [11] clause 6.1.3a, with the restriction that it shall be compliant with the profile given by Diameter Base Protocol as defined in RFC 6733 [12], except the cipher suites. A SEG may be used to terminate the NDS/IP IPsec tunnels.

To verify the mechanisms implemented to protect data and information in transfer to and from the SMSF's Diameter protocol-based SGd interface.

NOTE: This test case applies to the network function with SGd Diameter interface.

Network product documentation containing information about supported NDS/IP protocols is provided by the vendor.

A Diameter application node peer implementing the security protocol configured by the vendor shall be available.

SMSF documentation, stating which security protocols for protection of data in transit are implemented and which profiles in TS 33.310 [11] and TS 33.210 [10] are applicable, is provided by the vendor. The tester shall base the tests on the profile defined by 3GPP in Clause 6.2 of TS 33.310 [11].

For TLS/DTLS, the tester shall base the tests on the profile defined by 3GPP in Clause 6.1.3a of TS 33.310 [11] and Clause 6.2 of TS 33.210 [10], with the restriction that it shall be compliant with the profile given by Diameter Base Protocol as defined in RFC 6733 [12], except the cipher suites.

For IKE and IPsec, the tester shall base the tests on the profile defined by 3GPP in TS 33.210 [10].

Procedure and execution steps, expected results, expected format of evidence:

These are the same as for the test case in TS 33.117 [2], clause 4.2.3.2.4, excluding execution step 4, and the profiles as mentioned in requirement description shall be followed in pre-conditions.

TR 33.926 [4], clause Y.2.2.2, Diameter session information disclosure

Diameter session on SGd interface

TS 29.338 [8], clause 4.5; RFC 6733 [12], clause 8.8

SMSF supports implicit termination of SGd Diameter application sessions. The client (server) includes in its requests (responses) the Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1), as described in IETF RFC 6733 [12]. The server sets the Auth-Session-State AVP value to NO_STATE_MAINTAINED (1), irrespective of what value the client sets. Neither the Authorization-Lifetime AVP nor the Session-Timeout AVP be present in requests or responses [8].

To protect Diameter sessions, SMSF supports the following requirements:

1. Diameter session ID AVP be unique, i.e. uniquely identify the user session and distinguish the session from all other active sessions.

2. The session ID be generated by the Diameter application node that initiates the session.

Verify that the above Diameter session and session ID related requirements have been met.

• This text case is applicable only if network product supports Diameter SGd Interface

• The Diameter application node uses a session ID to identify a session between the node and its peer.

• The documentation should describe the algorithm used to generate the session IDs, for details see Section 8.8 in RFC 6733 [12].

1. The tester logs in the network product.

2. The tester sends SGd application request message as follows:

a. Auth-Session-State AVP is set to the value NO_STATE_MAINTAINED (1).

b. Neither the Authorization-Lifetime AVP nor the Session-Timeout AVP is present in requests.

c. The tester generates session ID as per the documentation and uses it as session ID AVP in the message.

1. The tester sends SGd application request message as follows:

a. Auth-Session-State AVP is set to the value STATE_MAINTAINED (0).

b. Authorization-Lifetime AVP and Session-Timeout AVP are present in request.

c. The tester generates session ID as per the documentation and uses it as session ID AVP in the message.

1. The tester checks the response for its request message in step 2 and 3. In both cases, the tester verifies that:

a. Auth-Session-State AVP is set to the value NO_STATE_MAINTAINED (1).

b. Neither the Authorization-Lifetime AVP nor the Session-Timeout AVP is present in response.

c. The session IDs in two request messages are different and unique.

1. The tester sends SGd application request message with same session ID in a row and checks the response.

2. The tester sends SGd application request message with different session ID in a row and checks the response.

3. The tester logs in with different user ID and sends SGd application request message with same session ID in step 2 and checks the response.

1. A confirmation from the tester that the Auth-Session-State AVP is indeed set correctly in response messages.

2. A confirmation from the tester that the neither the Authorization-Lifetime AVP nor the Session-Timeout AVP is present in response messages.

3. In case of a duplicate or non-unique session ID, an error response is generated with Result-Code AVP as DIAMETER_INVALID_AVP_VALUE 5004 and Session-ID AVP is added in Failed AVP.

4. A response message indicating success is received to the request message when session ID is unique.

A confirmation that the tester has confirmed that:

1. The session ID AVP follows the requirements 1 and 2 in the requirement description.

2. The correct Auth-Session-State, Authorization-Lifetime and Session-Timeout AVP configurations are used.

3. The network product does not accept duplicate session IDs.

Test result (Passed or not)

TR 33.926 [4], clause Y.2.2.1, Diameter filtering

Diameter filtering on the SGd interface

TS 29.338 [8], clause 6.3.2.2

TS 29.338 [8] defines the following commands and their command codes for the SGd application: MO-Forward-Short-Message-Request (OFR) - 83.8645, MO-Forward-Short-Message-Answer (OFA) - 83.8645, MT-Forward-Short-Message-Request (TFR) - 83.8646, MT-Forward-Short-Message-Answer (TFA) - 83.8646, Alert-Service-Centre-Request (ALR) - 83.8648 and Alert-Service-Centre-Answer (ALA) - 83.8648. It also mentions that the Application ID field for OFR, OFA, TFR, TFA commands allocated by IANA is 16.77313 and that for ALR, ALA commands is 16.77312.\ \ SMSF provides a mechanism, or rely on the other network function, to filter incoming Diameter messages on the SGd interface based on the Application IDs and command codes.

In particular, SMSF that supports filtering provides a mechanism:

1. To filter incoming Diameter messages on the SGd interface at the Application layer of the stack ISO/OSI.

2. To allow specified actions to be taken when a filter rule matches. In particular at least the following actions should be supported:

3. Discard: the matching message is discarded; no subsequent rules are applied and no answer is sent back.

4. Accept: the matching message is accepted.

5. Account: the matching message is accounted for i.e. a counter for the rule is incremented. This action can be combined with the previous ones. This feature is useful to monitor traffic before its blocking.

6. To enable/disable the logging for each rule for troubleshooting.

7. To filter on the basis of the value(s) of any portion of the protocol header.

8. To reset the accounting.

9. To disable/enable each defined rule.

To verify that the Network Product provides filtering for incoming Diameter messages on the SGd interface.

• This test case is applicable only if the network product supports Diameter SGd Interface and the embedded filtering capability

• The tester has the privileges to configure Diameter filtering rules on the network product.

• The vendor declares that Diameter filtering is enabled and provides a list of the filtering rules.

• The vendor includes a guideline to configure the Diameter filtering in the documentation accompanying the network product.

• A network traffic generator or a pcap file containing the Diameter messages is available.

• A network traffic analyser on the network product (e.g. tcpdump) is available.

1. The tester logs in the network product.

2. The tester configures the network product with the following rules:

a. Accept messages that meet the filtering rules supported by the vendor on the SGd interface.

b. Discard all other messages on the SGd interface.

c. For each rule above the accounting is also enabled.

1. The tester turns on the network traffic analyser on the SGd interface.

2. The tester sends Diameter messages to the network product by replaying a pcap file or using a network generator, ensuring that the messages pass the supported filtering rules.

a. Using the network analyser, the tester verifies that the messages are correctly received by the network product.

b. Using the accounting, the tester verifies that the messages are not discarded because response messages are sent back by the network product.

1. The tester sends Diameter messages to the network product by replaying a pcap file or using a network generator, ensuring the messages do not pass the supported filtering rules.

a. Using the network analyser, the tester verifies that the messages are discarded by the network product.

b. Using the accounting, the tester verifies that the messages are discarded and that no response is sent back by the network product.

• For step 4 the tester receives successful Diameter response messages from the network product.

• For step 5 the tester receives no response from the network product.

• For steps 4 and 5, messages that pass and do not pass the filtering rules are correctly accounted.

A testing report provided by the testing agency which will consist of the following information:

• The used tool(s) name and version information

• Settings and configurations used

• Pcap trace

• Screenshot

Test result (Passed or not)

TR 33.926 [4], Annex Y.2.2.1, Diameter filtering

Disabling peer discovery on the SGd interface

RFC 6733 [12], clause 5.2;

Capability Exchange Request (CER) and Capability Exchange Answer (CEA) are Diameter messages used on SGd interface to discover diameter nodes and know their capability. If peer discovery is enabled, an attacker can connect to the SMSF and learn about its capabilities by sending CER messages. Network products with the SGd interface should be configured to accept only known peers.

To protect SMSF from attacks by unknown peers (attackers), it supports the following requirements:

1. It maintains list of all trusted nodes with static IP addresses in a peer table.

2. It is configured only to respond to the CER messages from trusted nodes listed in the peer table, and it ignores CERs from all other nodes.

To verify that the SMSF ignores requests from any unauthorized nodes that tries to discover its capabilities.

• This test case is applicable only if the network product supports Diameter SGd Interface.

• The tester has the privileges to configure network product's peer table to include only directly connected peers with static IP addresses.

• The vendor declares that peer discovery is disabled on the network product.

1. The tester logs in the network product.

2. The tester configures the peer tables of the network product with a list of static IP addresses.

3. The tester configures its source IP using one from the list in the network product's peer table. The tester then sends a CER message by replaying a pcap file or using a network generator:

a. Using the network analyser, the tester verifies that the message is correctly received by the network product.

b. The tester verifies that the network product responds with a CEA.

1. The tester configures its source IP to one that is not in the peer table list of the network product. The tester then sends a CER message by replaying a pcap file or using a network generator:

a. Using the network analyser, the tester verifies that the message is discarded by the network product.

b. The tester verifies that the network product does not respond with a CEA.

The network product responds with a CEA for CERs received from the peers listed in its peer table and ignores CERs from all others.

A testing report provided by the testing agency which will consist of the following information:

• The used tool(s) name and version information

• Settings and configurations used

• Pcap trace

• Screenshot

Test result (Passed or not)

TR 33.926 [4], clause Y.2.3.1, Map filtering

Map filtering on the SS7 interface

TS 33.204 [13], clause 4.1; TS 29.002 [9], clause 12

TS 33.204 [13], clause 4.1 mentions "TCAPsec does not validate the TCAP user payload content. Message screening functions for particular message types may be needed on top of TCAPsec." TS 29.002 [9] defines the Short Message Service (SMS) management services in clause 12.\ \ Hence, message filtering mechanism shall be used on Map-based SS7 interface of SMSF to filter and allow only SMS management services related messages which are applicable for SMSF, for example, MAP-MT-FORWARD-SHORT-MESSAGE service, MAP-MO-FORWARD-SHORT-MESSAGE service, and MAP-ALERT-SERVICE-CENTRE service.

In particular, SMSF that supports filtering provides a mechanism:

1. To filter incoming Map messages on the SS7 interface at the Application layer of the stack ISO/OSI.

2. To allow specified actions to be taken when a filter rule matches. In particular at least the following actions should be supported:

3. Discard: the matching message is discarded; no subsequent rules are applied and no answer is sent back.

4. Accept: the matching message is accepted.

To verify that the Network Product provides filtering for incoming Map messages on the SS7 interface.

• This test case is applicable only if the network product supports Map/SS7 Interface and the embedded filtering capability.

• The vendor declares that Map filtering is enabled and provides a list of the filtering rules.

• The network product is preconfigured with the following rules:

a. Accept messages that meet the filtering rules supported by the vendor on the SS7 interface.

b. Discard all other messages on the SS7 interface.

• A network traffic generator or a pcap file containing the Map messages is available.

1. The tester turns on the network traffic analyser on the SS7 interface.

2. The tester sends Map messages to the network product by replaying a pcap file or using a network generator, ensuring that the messages pass the supported filtering rules.

a. Using the network analyser, the tester verifies that the messages are correctly received by the network product.

1. The tester sends Map messages to the network product by replaying a pcap file or using a network generator, ensuring the messages do not pass the supported filtering rules.

a. Using the network analyser, the tester verifies that the messages are discarded by the network product.

• For step 4 the tester receives successful Map response messages from the network product.

• For step 5 the tester receives no response from the network product.

A testing report provided by the testing agency which will consist of the following information:

• The used tool(s) name and version information

• Settings and configurations used

• Pcap trace

• Screenshot

Test result (Passed or not)