5.1.3 Interactions with SCCP segmentation

29.2043GPPArchitecture, functional description and protocol detailsRelease 17Signalling System No. 7 (SS7) security gatewayTS

When the incoming SCCP message makes use of SCCP segmenting (i.e. several XUDT messages are received rather than one UDT or a single XUDT message) the SS7 Security Gateway has to perform reassembling before processing the message, and it may have to perform segmenting before sending the processed message.

It may happen that the received SCCP message (containing an unprotected TCAP user payload) is not segmented (UDT or single XUDT), but after security processing the message’s length is increased, so that the processed message needs to be segmented before it is sent. This situation may be undesired (since transfer of XUDT messages is not guaranteed by all transit networks) but cannot be avoided by the SS7 Security Gateway (see note).

Note: The support of message segmentation at the SCCP layer in all transit networks could be enforced by mandating the usage of the White Book SCCP [9]. GSMA would work with International Carriers to ensure that fully operationally-verified support of XUDT is available before TCAPsec gateways are deployed.

It may also happen that the received (protected) message is segmented (several XUDTs), but after security processing the message’s length is decreased, so that the processed message does not need to be segmented before it is sent. In this case the de-protecting SS7 Security Gateway needs to know some SCCP-details of the original unprotected message as sent from the originating NE to the protecting SS7 Security Gateway. These original SCCP information needs to be transported within the TCAP-user parameter of the protected message. Depending on this information the de-protecting SS7-Security Gateway can decide whether to send a UDT or a single XUDT message towards the destination. .

In cases where the received unprotected message is not segmented but the (to be) sent protected message needs to be segmented, the SS7 Security Gateway has to replace the message’s SCCP calling party address with its own address. This is to guarantee uniqueness of the combination of the SCCP calling party address and the Segmentation local reference in the (to be) sent message. The original SCCP calling party address needs to be transported within the TCAP-user parameter of the (first segment of the) protected message.

If the received protected message contains an original SCCP calling party address within the TCAP-user parameter, the de-protecting SS7 Security Gateway has to replace the SCCP calling party address with the original SCCP calling party address before forwarding the de-protected message to the destination.

An SS7 Security Gateway that has sent a segmented, protected message with a replaced SCCP calling party address may receive an SCCP XUDTS message with its own address as called party address. In this case the SS7 Security Gateway shall retrieve the original SCCP calling party address, the original TCAP Message type and TCAP transaction id from the data parameter of the received XUDTS message and construct a UDTS message with unmodified Return cause, called party address replaced with the retrieved original calling party address, unmodified calling party address, and Data parameter containing the retrieved TCAP message type and TCAP transaction id, and forward it to the destination.