1. Obtain the name and location of the target software image file from either Oracle Software Delivery Cloud, https://edelivery.oracle.com/, or My Oracle Support, https://support.oracle.com, as applicable.
2. Provision platforms with the Oracle Communications Session Border Controller image file in the boot parameters.
3. Run the check-upgrade-readiness command and examine its output for any recommendations or requirements prior to upgrade.
4. Verify the integrity of your configuration using the ACLI verify-config command.
5. Back up a well-working configuration. Name the file descriptively so you can fall back to this configuration easily.
6. Refer to the Oracle Communications Session Border Controller Release Notes for any caveats involving software upgrades.
7. Do not configure an entitlement change on the Oracle Communications Session Border Controller while simultaneously performing a software upgrade. These operations must be performed separately.

The following items provide key information about upgrading and downgrading with this software version.

In the S-Cz9.1.0 release and later, the upgrade process automatically changes the former Fraud Protection list types named call-whitelist and call-blacklist to call-allowlist and call-blocklist. This change impacts rollback scenarios.

The S-Cz9.3.0 SBC release includes a Mocana version upgrade that generates important changes to the ciphers you should use with the SBC. The latest Mocana 7.0 software code disables weak ciphers/algorithms used by IKE-based IPsec tunnels. Removal of these weak ciphers is mandated by Oracle Security standards. If in use, you should consider replacing deprecated ciphers in your configuration.

You use this upgrade procedure to upgrade HA nodes to S-Cz9.3.0 software image when your SBC deployment has active IKE-based IPsec established tunnels operating with deprecated ciphers. If you have not set an entitlement for IPsec Trunking Sessions or if there are no ike-config or ike-interface configurations on your SBC, then you can safely ignore this upgrade procedure. Note also that IPsec tunnels established as part of IMS-AKA feature are not affected by this deprecation and should work as it is without any service disruption.

The following ciphers are deprecated for IKE-based IPsec tunnels:

• dh-group2—Configurable under ike-config, phase1-dh-mode and phase2-exchange-mode
• md5 and sha—Configurable under ike-sainfo, auth-algo
• 3des and null—Configurable under ike-sainfo, encryption-algo
• esp-null—Configurable under ike-sainfo, security-protocol

Assume that HA nodes A and B are running a pre-S-Cz9.3.0 software image. Assume that node A is active and node B is a standby. Follow the steps below to perform this upgrade:

1. On the Active node (assume A), identify the IKE-based IPsec tunnels that are using the weak ciphers. You can use the show security ike sad ike-interface <ike-interface-ip> ACLI command for this purpose.

   Consider the following example output.

   ORACLE#show security ike sad ike-interface 172.16.175.51
   Displaying the total (1) number of entries may take long and could affect system performance.
   Continue? [y/n]?: y
   Peer: 172.16.251.38:500 (NAT: No) Host: 172.16.175.51 State: Up
   IKEv2 Cookies: 0x9c840a66a6225f5e[I] 0x51829548c0e451df[R] rekeying in 179 seconds
   Child Peer IP: 172.16.251.38:0 Child SPI: 3487269395[I] 3402270211[O] Protocol: ESP TUNNEL Mode rekeying in 219 seconds

2. From the above output, using the child SA’s SPI, execute the show security ipsec sad <network-interface:vlan> detail spi <child-SA-SPI> command. Example, partial output is shown below.

   Outbound SPI: 1416790526
   Mirror SPI : 3719925232
   source-address : 192.168.209.219
   destination-address : 192.168.209.209
   source-port : 0
   destination-port : 0
   trans-proto : any
   vlan_id : 33
   ipsec-protocol : ESP
   ** encr-algo : 3des 
   ** auth-algo : SHA-1
   sa-installation-time : 2023-11-10 01:23:40.208
   sa-duration : 7838925
   sa-installation-complete : 0
   sa-installed-on-active : 0
   tunnel-source : 192.168.209.219
   tunnel-destination : 192.168.209.209
   byte count limit -
   hard ms: 0xFFFFFFFF, hard ls: 0xFFFFFFFF
   soft ms: 0xFFFFFFFF, soft ls: 0xFFFFFFFF
   time limit -
   hard ms: 0x 0, hard ls : 0xFFFFFFFF
   soft ms: 0x 0, soft ls: 0xFFFFFFFF
   sequence number -
   ms: 0x 0, ls: 0x 0
   packets -
   0x 0

   From the above output, you can identify the IPsec SA’s that use weak ciphers by looking at the auth-algo and encr-algo parameters, denoted with two asterisks above (**).

   Once the tunnels using the weak ciphers are identified, make note of the following information such as the ike-interface IP of the SBC used for the tunnel, peer IP and port, IPsec SA source and destination IP, SPI (Security Policy Identifier) and so forth.

   Note:

   Tunnels already established using stronger ciphers should not have any impact during the upgrade.
3. Load node B with the S-Cz9.3.0 image, reboot and let the node come up as a standby node.

   The standby node loaded with S-Cz9.3.0 software can now show verify-config errors for ike-sainfo and ike-config configurations that have weak ciphers configured. You can also run the check-upgrade-status command to show the IKE/IPsec specific configurations that use weak ciphers. Applicable error messages from the check-upgrade-status or verify-config commands include:

   • ERROR: Security-policy [sec-pol4500] has ike-sainfo-name [ike-sainfo] which contains the following removed authentication algorithm(s): sha1
   • ERROR: Security-policy [sec-pol4500] has ike-sainfo-name [ike-sainfo] which contains the following removed encryption algorithm(s): 3des
   • ERROR: Security-policy [second4500] has ike-sainfo-name [secondikesa] which contains the following removed authentication algorithm(s): sha1
   • ERROR: Security-policy [second4500] has ike-sainfo-name [secondikesa] which contains the following removed encryption algorithm(s): 3des
4. From the previous step, update the weaker algorithms to the stronger ones in your ike-sainfo and ike-config configurations.
   • ike-sainfo updates the IPsec SA algorithms
   • ike-config updates the IKE DH (Diffie Hellman) algorithms

   Verify your updates using the following methods:

   • Ensure that the errors reported in the check-upgrade-status or the verify-config command go away after you have updated the configurations.
   • Identify the peer node, identified in Step 1, involved in the tunnel and ensure that the peer endpoint is configured with stronger algorithms (not the ciphers deprecated at the SBC) to avoid potential failures during the tunnel re-establishment in step 6.
   • Run the show running-configuration ike-interface command to identify the list of IKE interfaces configured as initiators by looking at the ike-mode parameter and identify all the tunnels used by the initiator-mode IKE interfaces from the information gathered from Step 1
5. From the information gathered from Step 1 that identifies the tunnel using weaker ciphers, on node A, execute any of the following ACLI commands to delete the existing tunnel:
   • security ipsec delete tunnel ike-interface <ike-interface-ip> ike-peer <PeerIP:port>
   • security ipsec delete userId <userId> [<peer-ip-address[:Port]>]
   • security ipsec delete tunnel ike-interface <ip> all (Beware this command may delete multiple tunnels)
   • security ipsec delete tunnel destIP <ip> spi <spi>

   Ensure that the specific tunnel using the weak ciphers is deleted on both HA nodes. This can be done by running show security ike sad ike-interface <ike-interface-ip> and/or the show security ipsec sad <network-interface:vlan> detail commands.

   Note:

   When you delete the Active tunnel of weaker algorithms on node A, then incoming calls on this tunnel will fail until node B becomes the Active node using stronger algorithms.
6. Load node A with S-Cz9.3.0 and reboot. Node B becomes the Active node.
7. On the active node, perform this step only for the tunnels that have IKE interfaces configured in initiator mode using the information collected from step 3. Establish the deleted tunnels from step 4 using either of the following commands:
   • ping <peer-ip> <network-interface:vlan> <source-ike-interface-ip>
   • ping <peer-ip>
8. Verify that the new tunnel is up by executing the show security ike sad ike-interface <ike-interface-ip> command and/or the show security ipsec sad <network-interface:vlan> detail command to verify that IPsec traffic is passing through the established tunnel. For IKE interfaces that are configured as responder mode, the peer endpoint initiates the tunnel towards the SBC.

Once node A comes up as a standby node, the system synchronizes the new tunnel(s) (with stronger algorithms) information from the Active node to the standby node. You can ensure that any tunnel is present by executing the show security ike sad ike-interface <ike-interface-ip> command.

Also ensure that the tunnel is properly replicated on both nodes by comparing the output of the show security ike sad ike-interface <ike-interface-ip> and/or the show security ipsec sad <network-interface:vlan> detail commands.