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
tocompatibility
.
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.
- 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
- AES_CM_128_HMAC_SHA1_80
- AES_CM_128_HMAC_SHA1_32
- ARIA_CM_192_HMAC_SHA1_80
- ARIA_CM_192_HMAC_SHA1_32
- 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
- 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.