Manual Inter-domain Security Association and Key Management procedures is subject to roaming agreements. Some important parts of an inter-domain Security Association and Key Management agreement are:

• to define how to carry out the initial exchange of TCAPsec SAs;
• to define how to renew the TCAPsec SAs;
• to define how to withdraw TCAPsec SAs (including requirements on how fast to execute the withdrawal);
• to decide if fallback to unprotected mode is to be allowed;
• to decide on key lengths, algorithms, protection mode, and SA expiry times, etc (TCAPsec SAs are expected to be fairly long lived).

An SA being used by an SS7-SEG for incoming traffic expires when it reaches its hard expiry time. When this occurs, the SS7-SEG can no longer use that SA to process incoming TCAPsec traffic. If a new additional valid SA is installed into the SS7-SEG, the "old" one shall still be kept until it reaches its hard expiry time, so as to be able to accept incoming traffic still received under the "old" SA. An SA being used by an SS7-SEG for outgoing traffic expires when it reaches its soft expiry time. When this occurs, the SS7-SEG shall start using another valid SA. If no such valid SA exists, the SS7-SEG continues to use the "old" SA until it reaches its hard expiry time or another valid SA effectively becomes available. In case the current SA gets compromised, a new valid SA should be made immediately available to all SS7-SEG, which should then stop using the compromised SA and delete it. To ease SA renewal, both networks may decide to set up several TCAPsec SAs in advance so that SS7-SEGs can automatically switch from one SA to another SA. In such a situation, the TCAPsec SAs would have different soft and hard expiry times. When more than one valid SA is available, the SS7-SEG chooses the one with the earliest soft expiry time.

Manual Local Security Association Distribution is executed entirely within one network and is consequently at the discretion of the administrative authority. The requirement on the manual distribution procedures can be summarized as follows:

• Procedures for transporting the relevant TCAPsec SA to the SS7-SEG shall be defined. In order to ensure that the TCAPsec SA are present when needed, all valid TCAPsec SA should be distributed to all SS7-SEG as soon as they are available.
• Procedures for revocation of TCAPsec SAs shall be defined.

By applying a migration strategy which is coordinated between the two PLMN operators (A and B) it can be assured that protected messages are not sent from PLMN A to PLMN B (and vice versa) before operator B confirms completion of SS7-SEG introduction in his network. In order to avoid traffic interruption during the transition phase from unprotected to protected message transfer between tw' operators' PLMNs the following course of action is recommended: Precondition: It is assumed that neither operator A, nor operator B have activated TCAPsec for the TCAP user application part(s) that needs protection and now are going to set up use of TCAP user security for traffic to and from each other.

1. Operator A negotiates Security Associations with operator B and stores the SAs in the SAD. Both operators also agree on the policy that shall be applied for the different TCAP user application parts of the messages that needs to be exchanges between the PLMNs.
2. Operator A modifies the Security Policy in his gateways as follows: Messages received from operator B's PLMN should be protected according to the indicated protection mode by the SPD; however fallback to unprotected mode is allowed, i.e. unprotected messages received from'operator B's PLMN are not blocked. This means that incoming messages with an SCCP calling party address pointing to operator B are accepted by PLMN A. Operator A does not send protected messages yet.
3. When Operator A has completed step 2 in all his SS7-SEGs, he informs Operator B.
4. When Operator A receives confirmation that operator B also has performed step 2, Operator A modifies the Security Policy in his gateways as follows: Outgoing messages sent to operator B's PLMN shall be protected as indicated by the SPD.
5. When Operator A has completed step 4 in all his SS7-SEGs, he informs Operator B which can then perform step 4 and 6 towards Operator A.
6. When Operator A receives confirmation from Operator B that he has performed step 4, Operator A modifies the Security Policy in his gateways as follows: Fallback to unprotected mode is not allowed, i.e. unprotected messages received from'operator B's PLMN will be blocked.

In order to avoid traffic interruption during the transition phase from protected to unprotected message transfer between two operators' PLMNs, the following course of action is recommended: Precondition: It is assumed that operator A has already successfully set up the use of TCAP user security for traffic to and from operator B and is now going to remove use of TCAP user security for traffic to and from operator B.

1. Operator A modifies the Security Policy in his gateways as follows: Messages received from operator B's PLMN may still be protected according to the stored SA, however fallback to unprotected mode is allowed.
2. When Operator A has completed step 1 in all his SS7-SEGs, he informs Operator B.
3. When Operator A receives confirmation from Operator B that all SS7-SEGs in Operator B's PLMN have been set up to allow fallback to unprotected mode, Operator A changes the SPD entries to send unprotected outgoing messages via his SS7-SEGs, but allow the reception of protected messages from network B.
4. When Operator A has completed step 3 in all his SS7-SEGs, he informs Operator B.
5. When Operator A receives confirmation from Operator B that the SPD entries were changed to unprotected in all SS7-SEGs of Operator B's network, Operator A performs the similar change in his SS7-SEGs.

In order to avoid traffic interruption during the phase where the used protection mode is modified in the SS7-SEGs' SPDs, the following course of action is recommended: Precondition: It is assumed that operator A's policy is to protect all messages exchanged with operator B's PLMN with protection mode "integrity+authenticity"; now both Operators are going to modify the policy to protect messages sent to the other PLMN with protection mode "integrity+authenticity+confidentiality".

1. Operator A and B both modify the SPD by adding "integrity+authenticity+confidentiality" to the acceptable protection modes, i.e. they will now allow both "integrity+authenticity+confidentiality" and "integrity+authenticity" as acceptable protection modes, but outgoing messages are still sent with "integrity+authenticity".
2. When step 1 is completed in all SS7-SEGs of Operator B's PLMN, Operator A is informed. Similarly Operator A will inform Operator B after performing the actions of Step 1.
3. When Operator A (or Operator B) receives confirmation from Operator B (or Operator A) that the SPDs in all SS7-SEGs have been updated to accept the new protection mode in addition to the old one, Operator A (or operator B) modifies the SPD such that outgoing messages in his SS7-SEGs towards Operator B (or operator A) are send with only with protection mode "integrity+authenticity+confidentiality".
4. When step 3 is completed in all SS7-SEGs of Operator A's (or Operator B's) PLMN, he informs Operator B (or Operator A).
5. When receiving confirmation that the SPDs have been updated in all SS7-SEGs of Operator A (or Operators B's) PLMN, Operator B (or Operator A) modifies the SPD by removing "integrity+authenticity" from the acceptable protection modes.

If the serving network receives an mt-forward-SM MAP message which uses the TC_Continue to transfer the MAP payload then it is guaranteed that the SCCP calling party address of the (empty) TC_Begin message is authentic, otherwise the first TC-continue message would be sent to the falsified address. The correct message flow is guaranteed by the TCAP transaction capabilities (use of Transaction ID). Unfortunately there are some ways in which a fraudulent SMS Gateway operator (called the originator in bullets (a) and (b)) may try to circumvent the implicit SCCP address authentication provided by the TCAP handshake.

1. The originator includes a falsified SMS-GMSC address as SM-RP-OA in the mt-forward-SM payload carried by the TC-continue (third message in Figure D.1)
2. The originator tries to predict the TCAP transaction ID assigned by the serving node, which is to be used within the third message, and spoofs the third message without waiting for the second message. This attack has to be carried out within the right time window.

If TCAP handshake is to be used, the following measure shall be taken within the network of the serving node in order to counteract the spoofing possibilities of a malicious mt-Forward-SM originator. MEAS-1: If TCAP handshake is to be used, at least one of the following measures shall be taken within the network of the serving node in order to counteract the spoofing possibilities of a malicious mt-Forward-SM originator. MEAS-2a: MEAS-2b: The following grouping method may be used for an operator to gradually introduce the TCAP handshake for mt-Forward-SM messages. Define an 'operator group-1' as a trusted operator group and 'operator group-2' as an un-trusted operator group. Agree that group-1 uses the TCAP handshake, while group-2 does not use the TCAP handshake. As specified by TS 29.002 this requires that the SMS Gateway operators belonging to group-1 shall either use application context2 or 3 for mt-Forward-SM. The management of the two groups requires that the serving network shall implement a policy table of SCCP Calling Party Addresses for which a TCAP handshake is required. If the above described grouping method is used then the following measure shall be taken at the serving network in order to counteract the spoofing possibilities of a malicious mt-Forward-SM originator that tries to circumvent the policy table checks. MEAS-3: The benefit gained for operators that belong to group-1 is that spoofing of their SMS-GMSC-addresses is practically difficult if the policy table has been administrated accurately.

If the serving network sends an mo-forward-SM MAP message which uses the TC_Continue to transfer the MAP payload then it is guaranteed that the SCCP calling party address of the (empty) TC_Begin message is authentic, otherwise the first TC-continue message would be sent to the falsified address. The correct message flow is guaranteed by the TCAP transaction capabilities (use of Transaction ID). Unfortunately there are some ways in which a fraudulent serving (MSC or SGSN) operator (called the originator in bullets (a) and (b)) may try to circumvent the implicit SCCP address authentication provided by the TCAP handshake.

1. The originator includes a falsified MSISDN as SM-RP-OA within the mo-forward-SM payload carried by the TC-continue (third message in Figure D.2)
2. The originator tries to predict the TCAP transaction ID assigned by the serving node, which is to be used within the third message, and spoofs the third message without waiting for the second message. This attack has to be carried out within the right time window.

If TCAP handshake is to be used, the following measure may be taken within the network of the SMS Interworking MSC in order to counteract the spoofing possibilities of a malicious mo-Forward-SM originator. MEAS-1: If the TCAP handshake is to be used, then at least one of MEAS-2a and MEAS-2b of clause D.1 shall also be applied. The following grouping method may be used for an operator to gradually introduce the TCAP handshake for mo-Forward-SM messages. Define an 'operator group-1' as a trusted operator group and 'operator group-2' as an un-trusted operator group. Agree that group-1 uses the TCAP handshake, while group-2 does not use the TCAP handshake. As specified by TS 29.002 this requires that the MSC operators belonging to group-1 shall either use application context2 or 3 for mo-Forward-SM. The management of the two groups requires that the network of the SMS Interworking MSC shall implement a policy table of originating SCCP-addresses for which a TCAP handshake is required. If the above described grouping method is used then the following measure shall be taken at the network of the SMS Interworking MSC in order to counteract the spoofing possibilities of a malicious mo-Forward-SM originator that tries to circumvent the policy table checks. MEAS-3: The benefit gained for operators that belong to group-1 is that mo-Forward-SM spoofing for their subscribers, while roaming within group-1, becomes practically difficult if the policy table has been administrated accurately.