Upgrade Information

When you perform a software upgrade, you need to follow the paths presented in these Release Notes and use the same image types to achieve a hitless upgrade. This applies to both HA and non-HA deployments. The paths are presented below.

An example of different image types is upgrading a non-LI deployment with an LI image. Such non-hitless upgrades require that you reboot devices per your upgrade procedure, and then reboot all upgraded devices again to establish the new deployment type.

Supported Upgrade Paths

Always start the upgrade process with the latest patch version of your current release.

The SBC, ESBC, and SR support the following in-service (hitless) upgrade and rollback paths:

S-Cz9.0.0p12 (or higher) to S-Cz9.3.0
S-Cz9.1.0p10 (or higher) to S-Cz9.3.0
S-Cz9.2.0p4 (or higher) to S-Cz9.3.0

Note:

This support pertains to software upgrades of nodes in existing HA clusters. It does not pertain to upgrade scenarios when the hardware is being upgraded, such as scenarios that include an upgrade from Netra Server X5-2 to Oracle Server X7-2.

When upgrading to this release from a release older than the previous release, read all intermediate Release Notes for notification of incremental changes.

Upgrade Checklist

Before upgrading the Oracle® Enterprise Session Border Controller software:

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.
Provision platforms with the Oracle® Enterprise Session Border Controller image file in the boot parameters.
Run the check-upgrade-readiness command and examine its output for any recommendations or requirements prior to upgrade.
Verify the integrity of your configuration using the ACLI verify-config command.
Back up a well-working configuration. Name the file descriptively so you can fall back to this configuration easily.
Refer to the Oracle® Enterprise Session Border Controller Release Notes for any caveats involving software upgrades.
Do not configure an entitlement change on the Oracle® Enterprise Session Border Controller while simultaneously performing a software upgrade. These operations must be performed separately.

Upgrade and Downgrade Caveats

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

Acme Packet 3900 Platform

When you upgrade software, if the session-capacity is configured to a value greater than the 8000 supported sessions on the 3900, an upgrade from 8.4 to 9.0 (and above) may cuase an outage as the session-capacity is reset to 0 (not 8000).

Platform-Specific Downgrade Limitations

Do not attempt to downgrade your ESBC to a release not supported by your platform. See the Platform Support table for which platforms support which releases.

Connection Failures with SSH/SFTP Clients

If you upgrade and your older SSH or SFTP client stops working, check that the client supports the mimumum ciphers required in the ssh-config element. The current default HMAC algorithm is hmac-sha2-256; the current key exchange algorithm is diffie-hellman-group14-sha256. If a verbose connection log of an SSH or SFTP client shows that it cannot agree on a cipher with the ESBC, upgrade your client.

SSH Host Key Algorithms

The ESBC offers rsa-sha2-512 as the default host key algorithm. SSH clients that offer only a SHA1 hash algorithm, like ssh-rsa, are not supported; your SSH client must offer a SHA2 hash algorithm. If you receive a "no matching host key type found" error message, upgrade your SSH client to one that supports SHA2 host key algorithms.

Diffie-Hellman Key Size

In the context of TLS negotiations on SIP interfaces, the default Diffie-Hellman key size offered by the ESBC is 1024 bits. The key size is set in the diffie-hellman-key-size attribute within the tls-global configuration element.

While the key size can be increased, setting the key size to 2048 bits significantly decreases performance.

Default TLS Version

Releases prior to S-Cz9.2.0 do not support TLS1.3.
Release S-Cz9.3.0 does not support TLS 1.0 or TLS1.1.
If you are downgrading from this release to a release prior to S-Cz9.2.0, set your tls-version to compatibility.

Downgrade Caveat for NTP Configurations using an FQDN

If you create a realm-config for providing resolution of FQDNs for NTP servers through the wancom0 interface, Oracle recommends that you remove this wancom0 realm-config before downgrading to a version that does not support FQDNs for NTP servers. If you retain this configuration, you lose SSH and GUI access after the downgrade.

To recover from this issue, use console access to remove the wancom0 realm-config. Also remove the wancom0 phy-interface and network-interface.

If you configure FQDN resolution for NTP servers through a media interface, you can downgrade to a version that does not support this resolution without removing that configuration.

Upgrade Version Caveat from Session Delivery Manager

The Session Delivery Manager cannot direct upgrades from S-Cz9.1.0p6, S-Cz9.0.0p8 or S-Cz9.0.0p9 for HA deployments. See Knowledge Document # 2952935.1 for a detailed explanation.

Upgrading Transcoding Jitter Settings to S-Cz9.3.0

Most customers should benefit from this new dynamic adaptive feature, and require no intervention. However, if you have customized the previous xcode-jitter-buffer-min and xcode-jitter-buffer-max jitter buffer options settings, the ESBC retains these settings in the new S-Cz9.3.0 configuration. Specifically:

xcode-jitter-buffer-min—mapped to xcode-jitter-buffer-low-min and xcode-jitter-buffer-high-min
xcode-jitter-buffer-max—mapped to xcode-jitter-buffer-low-max and xcode-jitter-buffer-high-max

This mapping results in the same transcoding jitter buffer behavior performed in versions prior to S-Cz9.3.0. These behaviors do not make full use of the new adaptive feature. Also, the ESBC performs this mapping during boot-up in a way that does not permanently alter your configuration.

For a proper long-term migration, remove any previous xcode-jitter-buffer-min and xcode-jitter-buffer-max jitter buffer options settings from your configuration prior to your S-Cz9.3.0 upgrade. This allows the new adaptive features to take effect.

If needed, you can then modify the new options settings from their default values. Oracle recommends, however, that you use the S-Cz9.3.0 adaptive transcoding jitter buffer feature with the default settings, and only change those settings under the direction of Oracle support.

NPLI Sync During Upgrades

During an HA pair upgrade, when a switchover activates the standby which uses a newer image, the cached NPLI (Network Provided Location Information) will be deleted from the newly active ESBC before it actively expires. If configured, the default-location-string will be sent in subsequent messages. This issue persists until both HA nodes use the new image.

TLS Secure Renegotiation

In release S-Cz9.3.0, the ESBC requires the use of TLS Secure Renegotiation as described in RFC 5746 in order to counter the prefix attack described in CVE-2009-3555. If the devices attempting a TLS connection to the ESBC don’t support TLS Secure Renegotiation, the TLS handshake fails. Oracle recommends updating such devices to support TLS Secure Renegotiation.

SuppressAdditionalProvisional SPL Upgrade Caveat

If you are using the SuppressAdditionalProvisional SPL loaded on an ESBC version prior to version S-Cz9.3.0, and are upgrading to S-Cz9.3.0, remove this suppression SPL manually and reboot your system before you perform this upgrade. Instruction and explanation on removing an SPL is documented in the SBC Processing Language (SPL) Chapter of the ESBC ACLI Configuration Guide.

Entitlement Caveat for MSRP B2BUA Sessions Entitlement

Before upgrading the Acme Packet 3900 platform to S-Cz9.3.0, set your MSRP B2BUA Sessions entitlement on that system to zero. After the upgrade is complete, reset your MSRP B2BUA Sessions entitlements back to your desired value. That platform is not supporting this entitlement properly during upgrades.

Fraud Protection File Rollback Compatibility

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.

Previous versions of the software expect the list types formerly named call-whitelist and call-blacklist. Use either of the following methods to make older versions support the Fraud Protection file, which is stored in XML format in a file with an extension of .xml, .gz, or .gzip in the /code/fpe/ directory.

Back up of your existing Fraud Protection configuration file before upgrading to S-Cz9.1.0 or later, and use it for previous versions of the software in a rollback scenario.
Perform the upgrade to S-Cz9.1.0 or later, which automatically changes call-whitelist and call-blacklist to call-allowlist and call-blocklist. Before you rollback, edit your S-Cz9.1.0 Fraud Protection file by replacing call-allowlist and call-blocklist with call-whitelist and call-blacklist, respectively.

Note:
You do not need to reverse this method when you upgrade to S-Cz9.1.0 or later. The upgrade process makes the changes automatically.

HA Upgrade Procedure for Deprecated Ciphers

The S-Cz9.3.0 ESBC release includes a Mocana version upgrade that generates important changes to the ciphers you should use with the ESBC. 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 ESBC 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 ESBC, 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:

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

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 ESBC 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.
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
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 ESBC) 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
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.
Load node A with S-Cz9.3.0 and reboot. Node B becomes the Active node.
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>
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 ESBC.

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.

Optional Step

If you did not perform steps 3 through 7, here is the expected behavior:

The concerned IKEv2/IPsec tunnel that uses weak ciphers will work until the next (IKE or IPsec) rekey happens.
Once the IKE or IPsec rekey negotiation starts, it is likely that the tunnel establishment will fail during the rekey negotiation because ESBC or the peer node will attempt to negotiate weaker algorithms used during the original tunnel establishment.

You should be aware of this situation, and later update your ESBC configuration (ike-sainfo, ike-config) and, if needed, the peer configuration. Then re-establish applicable tunnels following steps 3 through 8 at your convenience.