5.1.4 Protocol details

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

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1.4.1 Transformation of unprotected message to protected message

The unprotected TCAP-user message is either transported within an SCCP UDT message or it is transported within a single SCCP XUDT message or it is segmented over several SCCP XUDT messages. Other SCCP message types are not subject to protection.

The transformation process is done in 3 steps:

Step 1: SCCP re-assembly of the unprotected message

In a first step the unprotected message is transformed into an intermediate unprotected representation which is made up of the following parameters:

SCCP Message type
SCCP Protocol class
SCCP Hop counter (optional)
SCCP Called party address
SCCP Calling party address
SCCP Segmentation local reference (optional)
SCCP Importance (optional)
SCCP Data (made up of the following parameters: TCAP Message type
TCAP orig. Transaction Id (optional)
TCAP dest. Transaction Id (optional)
TCAP Dialogue Portion (optional)
TCAP Component Portion (optional))

If the unprotected message was transported within an SCCP UDT message, the intermediate unprotected representation of the message takes the following values:

SCCP Message type UDT
SCCP Protocol class same as in the received UDT message
SCCP Hop counter absent
SCCP Called party address same as in the received UDT message
SCCP Calling party address same as in the received UDT message
SCCP Segmentation local reference absent
SCCP Importance absent
SCCP Data same as in the received UDT message

If the unprotected message was transported within a single SCCP XUDT message, the intermediate unprotected representation of the message takes the following values:

SCCP Message type XUDT
SCCP Protocol class same as in the received XUDT message
SCCP Hop counter same as in the received XUDT message
SCCP Called party address same as in the received XUDT message
SCCP Calling party address same as in the received XUDT message
SCCP Segmentation local reference absent
SCCP Importance same as in the received XUDT message
SCCP Data same as in the received XUDT message

If the unprotected message was segmented over several SCCP XUDT messages, the intermediate unprotected representation of the message takes the following values:

SCCP Message type XUDT
SCCP Protocol class same as in the first received XUDT message
SCCP Hop counter same as in the first received XUDT message
SCCP Called party address same as in the first received XUDT message
SCCP Calling party address same as in the first received XUDT message
SCCP Segmentation local reference same as in the first received XUDT message
SCCP Importance same as in the first received XUDT message
SCCP Data concatenation of the received segments (for details of the re-
assembly procedure see ITU-T Q.714 [9])

Step 2: Protection

In a second step the intermediate unprotected representation is transformed into an intermediate protected representation which is made up of the following parameters:

SCCP Hop counter (optional)
SCCP Called party address
SCCP Calling party address
SCCP Segmentation local reference (optional)
SCCP Importance (optional)
Original SCCP info (made up of the following parameters: Original SCCP Calling party address (optional)
Original SCCP Message type
Original SCCP Protocol class)
Original TCAP info (made up of the following parameters: Original TCAP Message type
otid (optional)
dtid (optional))
TCAPsec Security header
TCAPsec Cipher- or Cleartext
TCAPsecMAC

The intermediate unprotected representation of the message takes the following values:

SCCP Hop counter same as SCCP Hop counter in the intermediate
unprotected representation
SCCP Called party address same as in the intermediate unprotected representation
SCCP Calling party address same as in the intermediate unprotected representation
SCCP Segmentation local reference same as in the intermediate unprotected representation
SCCP Importance same as SCCP Importance in the intermediate
unprotected representation
Original SCCP info made up of the following parameters:
Original SCCP Message type same as SCCP Message type in the intermediate
unprotected representation
Original SCCP Protocol class same as SCCP Protocol class in the intermediate
unprotected representation
Original TCAP info made up of the following parameters:
Original TCAP Message type same as TCAP Message type in the intermediate
unprotected representation
TCAP otid same as TCAP orig. Transaction Id in the intermediate
unprotected representation
TCAP dtid same as TCAP dest. Transaction Id in the intermediate
unprotected representation
TCAPsec Security header See 3GPP TS 33.204 [8]
TCAPsec Cipher- or Cleartext result of applying the encryption function to the
concatenation of Dialogue Portion and Component
Portion of the intermediate unprotected representation
(ciphertext), or concatenation of Dialogue Portion and
Component Portion of the intermediate unprotected
representation(cleartext)
TCAPsec MAC result of applying the integrity function to the
concatenation of Security header and Cipher- or
Cleartext of the intermediate protected representation.

Step 3: SCCP segmentation of the protected message

In a third step the intermediate protected representation is transformed into a single SCCP UDT message, a single SCCP XUDT message, or several SCCP XUDT messages depending on the Original SCCP Message type of the intermediate protected representation and the need for segmentation as follows:

If the Original SCCP Message type in the intermediate protected representation takes the value "UDT" and the message need not be segmented, it is transformed into a single SCCP UDT message with following parameter values:

Message Type UDT
Protocol class same as Original SCCP Protocol class in the intermediate protected representation
Called party address same as SCCP Called party address in the intermediate protected representation
Calling party address same as SCCP Calling party address in the intermediate protected representation
Data (see below)

If the Original SCCP Message type in the intermediate protected representation takes the value "XUDT" and the message need not be segmented, it is transformed into a single SCCP XUDT message with following parameter values:

Message Type XUDT
Protocol class same as Original SCCP Protocol class in the intermediate protected representation
Hop counter same as Original SCCP Hop counter in the intermediate protected representation
Called party address same as SCCP Called party address in the intermediate protected representation
Calling party address same as SCCP Calling party address in the intermediate protected representation
Data (see below)
Segmentation absent
Importance same as Original SCCP Importance in the intermediate protected representation

If the Original SCCP Message type in the intermediate protected representation takes the value "UDT" and the message needs to be segmented, it is transformed into several SCCP XUDT message with following parameter values:

If the Original SCCP Message type in the intermediate protected representation takes the value "XUDT" and the message needs to be segmented, it is transformed into several SCCP XUDT message with following parameter values:

Message Type XUDT
Protocol class first segment: class 1 (in sequence delivery), return option: same as in Original SCCP Protocol class in the intermediate protected representation
subsequent segment: class 1 (in sequence delivery), return option: no special options
Hop counter same as Original SCCP Hop counter in the intermediate protected representation
Called party address same as SCCP Called party address in the intermediate protected representation
Calling party address if SCCP Segmentation Local reference is present in the intermediate protected representation: same as SCCP Calling party address in the intermediate protected representation;
otherwise: the SS7 Security Gateway’s own address
Data (segment of see below)
Segmentation see [9]; if SCCP Segmentation Local reference is present in the intermediate protected representation, the same value shall be used.
Importance same as Original SCCP Importance in the intermediate protected representation.

The SCCP Data parameter (re-assembled) shall take the following value:

TCAP Message type unidirectional
TCAP DialoguePortion absent
TCAP ComponentPortion one invoke component with:
invokeId (any legal value)
linkedId absent
operationCode local value 90 (secureTransport)
parameter ANY DEFINED BY operationCode

.$SS7-Secure-Transport-Operation-and-DataTypes {

itu-t identified-organization (4) etsi (0) mobileDomain (0)

gsm-Network (1) modules (3) ss7-Secure-Transport-Operation-and-DataTypes (27) version1 (1)}

DEFINITIONS

IMPLICIT TAGS

::=

BEGIN

EXPORTS

secureTransport

;

IMPORTS

OPERATION

FROM Remote-Operations-Information-Objects {

joint-iso-itu-t remote-operations(4)

informationObjects(5) version1(0)}

;

secureTransport OPERATION ::= {

ARGUMENT

SecureTransportArg

CODE local:90 }

SecureTransportArg ::= SEQUENCE {

originalSCCP-Info [0] OriginalSCCP-Info OPTIONAL,

originalTCAP-Info [1] OriginalTCAP-Info,

protectedPayload [2] ProtectedPayload

}

OriginalSCCP-Info ::= SEQUENCE {

originalSCCP-MessageType [0] OriginalSCCP-MessageType OPTIONAL,

— original SCCP-MessageType shall be present if it is different from the actual

— SCCP-Message type; otherwise it may be absent

originalSCCP-ProtocolClass [1] OriginalSCCP-ProtocolClass OPTIONAL

— originalSCCP-ProtocolClass shall be present if it is different from the actual

— SCCP-Protocol class (first segment); otherwise it may be absent.

originalSCCP-CallingPartyAddress [2] OriginalSCCP-CallingPartyAddress OPTIONAL,

— originalSCCP-CallingPartyAddress shall be present if and only if the actual

— SCCP Calling party address is the SS7 Security Gateway’s own address

}

OriginalSCCP-MessageType ::= ENUMERATED {

udt (9),

xudt (17) }

— this parameter shall take the value of the Original SCCP Message type from the

— intermediate protected representation

OriginalSCCP-ProtocolClass ::= OCTET STRING(SIZE(1))

— coded according to ITU-T Q.713

OriginalSCCP-CallingPartyAddress ::= OCTET STRING(SIZE(3..18))

— coded according to ITU-T Q.713

— Octet 1: Address indicator

— Octets 2 – n: Address

OriginalTCAP-Info ::= SEQUENCE {

originalTCAP-MessageType OriginalTCAP-MessageType,

otid OTID OPTIONAL,

dtid DTID OPTIONAL

}

OriginalTCAP-MessageType ::= ENUMERATED {

unidirectional (97),

begin (98),

end (100),

continue (101),

abort (103)}

— this parameter shall take the value of the Original TCAP Message type from the

— intermediate protected representation

OTID ::= OCTET STRING(SIZE(1..4))

— OTID shall take the value of the TCAP otid from the intermediate protected

— representation

DTID ::= OCTET STRING(SIZE(1..4))

— DTID shall take the value of the TCAP dtid from the intermediate protected

— representation

ProtectedPayload ::= OCTET STRING(SIZE(13..3438))

— The protected payload is the concatenation of

— 9 or 11 octets SecurityHeader,

— n octets ciphertext or cleartext, and

— 4 octets MAC

— The SecurityHeader is coded as follows (see 3GPP TS 33.204 [8]):

— Octets 1-4: SPI

— Octets 5-8: TVP. The TVP is a 32 bit time stamp. Its value is binary coded

— and indicates the number of intervals of 100 milliseconds

— elapsed since 1st January 2002, 0:00:00 UTC

— Octet 9: Indicator Byte with bits 7-1 spare and bit 0 if set indicates presence of

— Octets 10-11

— Octet 10: SS7 SEG-Id

— Octet 11: Prop

.#END

5.1.4.2 Transformation of protected message to unprotected message

The protected TCAP-user message is either transported within an SCCP UDT message or it is transported within a single SCCP XUDT message or it is segmented over several SCCP XUDT messages. Other SCCP message types are not subject to protection.

The transformation process is done in 3 steps:

Step 1: SCCP re-assembly of the protected message

In a first step the protected message is transformed into the intermediate protected representation (see chapter 5.1.4.1):

If the protected message was transported within an SCCP UDT message, the intermediate protected representation of the message takes the following values:

SCCP Hop counter absent
SCCP Called party address same as in the received UDT message
SCCP Calling party address same as in the received UDT message
SCCP Segmentation local reference absent
SCCP Importance absent
Original SCCP info
Original SCCP Calling party address absent
Original SCCP Message type UDT
Original SCCP Protocol class same as SCCP Protocol class in the received UDT message
Original TCAP info
Original TCAP Message type same as Original TCAP Message type in the TCAP-invoke
component parameter of the received message
otid same as otid in the TCAP-invoke component parameter of the
received message
dtid same as dtid in the TCAP-invoke component parameter of the
received message
TCAPsec Security header same as received in the TCAP-invoke component parameter of the
received message
TCAPsec Cipher- or Cleartext same as received in the TCAP-invoke component parameter of the
received message
TCAPsec MAC same as received in the TCAP-invoke component parameter of the
received message

If the protected message was transported within a single SCCP XUDT message, the intermediate protected representation of the message takes the following values:

SCCP Hop counter same as in the received XUDT message
SCCP Called party address same as in the received XUDT message
SCCP Calling party address same as in the received XUDT message
SCCP Segmentation local reference absent
SCCP Importance same as in the received XUDT message
Original SCCP info
Original SCCP Calling party address absent
Original SCCP Message type same as OriginalSCCP-MessageType in the TCAP-invoke
component parameter of the received message
Original SCCP Protocol class same as OriginalSCCP-ProtocolClass in the TCAP-invoke
component parameter of the received message
Original TCAP info
Original TCAP Message type same as Original TCAP Message type in the TCAP-invoke
component parameter of the received message
otid same as otid in the TCAP-invoke component parameter of the
received message
dtid same as dtid in the TCAP-invoke component parameter of the
received message
TCAPsec Security header same as received in the TCAP-invoke component parameter of the
received message
TCAPsec Cipher- or Cleartext same as received in the TCAP-invoke component parameter of the
received message
TCAPsec MAC same as received in the TCAP-invoke component parameter of the
received message

If the protected message was transported within several SCCP XUDT message, the intermediate protected representation of the message takes the following values:

SCCP Hop counter same as in the first received XUDT message
SCCP Called party address same as in the first received XUDT message
SCCP Calling party address same as in the first received XUDT message
SCCP Segmentation local reference same as in the first received XUDT message
SCCP Importance same as in the first received XUDT message
Original SCCP info
Original SCCP Calling party address same as OriginalSCCP-CallingPartyAddress in the TCAP-invoke
component parameter of the received reassembled message
Original SCCP Message type same as OriginalSCCP-MessageType in the TCAP-invoke
component parameter of the received reassembled message
Original SCCP Protocol class same as OriginalSCCP-ProtocolClass in the TCAP-invoke
component parameter of the received reassembled message
Original TCAP info
Original TCAP Message type same as OriginalTCAP-MessageType in the TCAP-invoke
component parameter of the received reassembled message
otid same as otid in the TCAP-invoke component parameter of the
received reassembled message
dtid same as dtid in the TCAP-invoke component parameter of the
received reassembled message
TCAPsec Security header same as received in the TCAP-invoke component parameter of the
received reassembled message
TCAPsec Cipher- or Cleartext same as received in the TCAP-invoke component parameter of the
received reassembled message
TCAPsec MAC same as received in the TCAP-invoke component parameter of the
received reassembled message

Step 2: De-Protection

In a second step the intermediate protected representation is transformed into an intermediate unprotected representation (see chapter 5.1.4.1):

The intermediate unprotected representation of the message takes the following values:

SCCP Message type same as OriginalSCCP-MessageType from the TCAP-invoke
component’s parameter of the intermediate protected
representation
SCCP Protocol class same as OriginalSCCP-ProtocolClass from the TCAP-invoke
component’s parameter of the intermediate protected
representation
SCCP Hop counter same as SCCP Hop counter in the intermediate protected
representation
SCCP Called party address same as SCCP Called party address in the intermediate
protected representation
SCCP Calling party address if OriginalSCCP-CallingPartyAddress is present in the
intermediate protected representation, its value is taken;
otherwise same as SCCP Calling party address of the
intermediate protected representation
SCCP Segmentation local reference if SCCP Message type in the intermediate unprotected
representation is XUDT, then same as in the intermediate protected representation; otherwise absent.
SCCP Importance same as in the intermediate unprotected representation
SCCP Data :
TCAP Message type same as OriginalTCAP-MessageType in the intermediate
protected representation
TCAP orig. Transaction Id same as otid in the intermediate protected representation
TCAP dest. Transaction Id same as dtid in the intermediate protected representation
TCAP Dialogue Portion (optional) First part of the cleartext (as indicated by TAG and LENGTH
according to BER). If encryption was applied then ciphertext
needs to be converted first to cleartext
TCAP Component Portion (optional)) second part of the cleartext (as indicated by TAG and
LENGTH according to BER). If encryption was applied then
ciphertext needs to be converted first to cleartext

Step 3: SCCP segmentation of the unprotected message

In a third step the intermediate unprotected representation is transformed into a single SCCP UDT message, a single SCCP XUDT message, or several SCCP XUDT messages depending on the SCCP Message type of the intermediate unprotected representation and the need for segmentation as follows:

If the SCCP Message type in the intermediate unprotected representation is "UDT", it is transformed into a single SCCP UDT message with following parameter values:

Message Type UDT
Protocol class same as SCCP Protocol class in the intermediate unprotected representation
Called party address same as SCCP Called party address in the intermediate unprotected representation
Calling party address same as SCCP Calling party address in the intermediate unprotected representation
Data same as SCCP Data in the intermediate unprotected representation

If the SCCP Message type in the intermediate unprotected representation is "XUDT" and the message does not need to be segmented, it is transformed into a single SCCP XUDT message with following parameter values:

Message type XUDT
Protocol class same as SCCP Protocol class in the intermediate unprotected representation
Hop counter same as SCCP Hop counter in the intermediate unprotected representation
Called party address same as SCCP Called party address in the intermediate unprotected representation
Calling party address same as SCCP Calling party address in the intermediate unprotected representation
Data same as SCCP Data in the intermediate unprotected representation
Segmentation absent
Importance same as SCCP Importance in the intermediate unprotected representation

If the SCCP Message type in the intermediate unprotected representation is "XUDT" and the message needs to be segmented, it is transformed into several SCCP XUDT message with following parameter values:

Message type (all segments) XUDT
Protocol class (first segment) class 1 (in sequence delivery), return option: same as in SCCP Protocol
class of the intermediate unprotected representation
(subsequent segments) class 1 (in sequence delivery), return option: no special options
Hop counter (all segments) same as SCCP Hop counter in the intermediate unprotected representation
Called party address (all segments) same as SCCP Called party address in the intermediate unprotected
representation
Calling party address (all segments) same as SCCP Calling party address in the intermediate unprotected
representation
Data segment of SCCP Data from the intermediate unprotected representation
(see ITU-T Q.714 [9])
Segmentation see [9]. Local reference shall be taken from the intermediate unprotected
representation
Importance (all segments) same as SCCP Importance in the intermediate unprotected representation

5.1.4.3 Handling of received XUDTS messages and UDTS messages

An SS7 Security Gateway shall not try to re-assemble XUDTS messages, since the SCCP option "return on error" is not set for subsequent XUDT segments. As a consequence the SS7 Security Gateway shall not try to protect or de-protect XUDTS messages (fragments) or UDTS messages. However, special handling of XUDTS messages and UDTS messages is required as follows:

Outbound direction

Instead of re-assembling and protecting the XUDTS messages or protecting UDTS messages, the SS7 Security Gateway shall remove the TCAP Dialogue Portion and the TCAP Component Portion from the SCCP Data parameter before sending the XUDTS message or UDTS message. This is in order not to pass the cleartext (or fragment of the cleartext) in outbound direction. SCCP message type and addresses shall not be changed.

An example is shown in figure 5.1.4.3-1: A transit node in PLMN 2 cannot deliver the UDT message and therefore returns an UDTS message. SS7 Security Gateway 2 in PLMN 2 removes the cleartext (TCAP dialogue portion and TCAP component portion) from the SCCP data parameter. SS7 Security Gateway 1 in PLMN 1 recognizes that the received UDTS message does not contain a TCAP unidirectional message with a secure transport invoke component and therefore it does not modify the SCCP message.

Figure 5.1.4.3-1: XUDTS messages and UDTS messages (Outbound direction)

Inbound direction

Instead of re-assembling and de-protecting the XUDTS messages or de-protecting UDTS messages, the SS7 Security Gateway shall analyze the SCCP Called party address. If it matches with the SS7 Security Gateway’s own address, it shall recover the OriginalSCCP-CallingPartyAddress from the (fragment in the) data parameter and replace the SCCP Called party address with the recovered value. In any case the SS7 Security Gateway shall recover and analyze the TCAP Message type from the (fragment in the) data parameter. If the recovered value is "unidirectional" and a invoke component with operation code "secure transport" is included, the SS7 Security Gateway shall recover the originalTCAP-MessageType, otid, and dtid from the OriginalTCAP-Info, replace the TCAP Message type with the original TCAP-MessageType, insert otid and dtid and remove the remaining material from the SCCP data parameter. If the received message is an XUDTS message and the original SCCP Message type was UDT then the SS7 Security shall modify the SCCP Message type to UDTS.

An example is shown in figure 5.1.4.3-2: A transit node in a transit network cannot deliver the XUDT messages and therefore returns an XUDTS message (note that the second XUDT does not have the SCCP return option set). SS7 Security Gateway 1 in PLMN 1 recognizes that the received XUDTS message does contain a TCAP unidirectional message with a secure transport invoke component and therefore, since the original SCCP-MessageType is UDT, modifies the SCCP Message type from XUDTS to UDTS. Furthermore, the TCAP MessageType is modified from unidirectional to the original TCAP-MessageType, the Transaction Ids are inserted, and the remaining material (fragment of the ciphertext) is removed.
In addition the SS7 Security Gateway 1 in PLMN 1 recognizes that the received XUDTS message does contain SS7 Security Gateway 1’s own address as SCCP Called party address and therefore replaces it with the original SCCPCalling party address.

Figure 5.1.4.3-2: XUDTS messages and UDTS messages (inbound direction)

Annex A (informative):
Change history

Change history
Date	Meeting	TDoc	CR	Rev	Cat	Subject/Comment	New version
2006-06	CT#32	CP-060320				Approved as version 7.0.0	7.0.0
2006-09	CT#33	CP-060413	0001			Addition of abbreviations and correction of a note	7.1.0
2008-12	CT#42					Upgraded unchanged from Rel-7	8.0.0
2009-12	–	–	–			Update to Rel-9 version (MCC)	9.0.0
2011-03	–	–	–			Update to Rel-10 version (MCC)	10.0.0
2012-09	–	–	–			Update to Rel-11 version (MCC)	11.0.0
2014-09	–	–	–			Update to Rel-12 version (MCC)	12.0.0
2015-12	CT#70	–	–			Update to Rel-13 version (MCC)	13.0.0
2017-03	CT#75	–	–			Update to Rel-14 version (MCC)	14.0.0
2018-06	CT#80	–	–			Update to Rel-15 version (MCC)	15.0.0
2020-07	CT#88e	–	–			Update to Rel-16 version (MCC)	16.0.0
2022-04	–	–	–	–	–	Update to Rel-17 version (MCC)	17.0.0