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 AP3900, an upgrade from 8.4 to 9.0 (and above) may cause an outage as the session-capacity is reset to 0 (not 8000).

Platform-Specific Downgrade Limitations

Do not attempt to downgrade your SBC 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 SBC, upgrade your client.

SSH Host Key Algorithms

The SBC 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 SBC 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.
  • Releases S-Cz9.3.0 and S-Cz10.0.0 do 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-Cz10.0.0

Most customers should benefit from the 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 SBC retains these settings in the new configurations. 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 SBC 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 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 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 SBC 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 and later, the SBC 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 SBC 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 SBC version prior to version S-Cz9.3.0, and are upgrading to S-Cz9.3.0 or later, 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 SBC Configuration Guide.

Entitlement Caveat for MSRP B2BUA Sessions Entitlement

Before upgrading the Acme Packet 3900 platform to S-Cz9.3.0 or later, 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.

Removed TLS Ciphers

Release S-Cz9.3.0p3 and later removes support for TLS1.0 and TLS1.1. The option parameter in security-config is reset to "sslmin=tls1.2" if it was previously set to either "sslmin=tls1.0" or "sslmin=tls1.1". You can no longer select either "tlsv1" or "tlsv11" for tls-version in the tls-profile element.

Release S-Cz9.3.0p3 and later removes support for the following weak ciphers:
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_AES_128_CCM_8_SHA256
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA
  • TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_NULL_SHA256
  • TLS_RSA_WITH_NULL_SHA
  • TLS_RSA_WITH_NULL_MD5

The ALL value is also removed, and DEFAULT is now the only cipher list. As a result, the cipher-list in a tls-profile is reset to DEFAULT if it was previously set to ALL.

Updated SRTP Cryptographic Lists

Release S-Cz9.3.0p3 updates the crypto-list attribute in the sdes-profile element. The crypto-list attribute supports the following ciphers on the Acme Packet 6350, Acme Packet 6400, and Acme Packet 4600:
  • AES_CM_128_HMAC_SHA1_80
  • AES_CM_128_HMAC_SHA1_32
  • ARIA_CM_192_HMAC_SHA1_80
  • ARIA_CM_192_HMAC_SHA1_32
The crypto-list attribute supports the following ciphers on the Acme Packet 3900, Acme Packet 4900, Acme Packet 1100, and virtual platforms:
  • AES_CM_128_HMAC_SHA1_80
  • AES_CM_128_HMAC_SHA1_32
  • AES_256_CM_HMAC_SHA1_80
  • AEAD_AES_256_GCM

Removed IKE Algorithms

Release S-Cz9.3.0p3 and later includes the following IKE-related changes:
  • Removes hmac-md5-96 from the auth-alg-list attribute in the ims-aka-profile element.
  • Removes des-ede3-cbc from the encr-alg-list attribute in the ims-aka-profile element.
  • Removes the following values from the auth-algo attribute in the ike-sainfo element:
    • xcbc
  • Removes the following values from the auth-algo attribute in the manual element:
    • aes-xcbc-mac

Certificates Signature Algorithm

If you previously created a certificate using a weak signature algothism or message digest like MD5 or SHA1, you must create a new certificate using SHA256. Use show security certificates to view which signature algothism is used.

HMR Regex Matching

An upgrade to Lua affects how the SBC adds headers on outgoing messages. When the header contains multiple values, the order of the values cannot be guaranteed. As a result, your regex patterns must not assume any specific order to the values of a header.

Session Translations

Both translation-rules and session-translation elements have significantly changed in release S-Cz9.2.0. A backup configuration from release S-Cz9.1.0 or earlier will not be compatible with S-Cz9.2.0 or later (including in S-Cz10.0.0), and vice versa. Create a backup of the existing configuration before performing an upgrade as the changes to the translation-rules and session-translation elements are not backward compatible, during a downgrade.

When upgrading to S-Cz10.0.0 from S-Cz9.1.0 or earlier, the SBC converts the older translation-rules and session-translation configuration elements to their new format. Translation rules and session translations will continue to work as before. A rules-called translation rule in release S-Cz9.1.0 and earlier will be upgraded in S-Cz10.0.0 to two separate translation rules: one that modifies the To header and one that modifies the Request URI.