Bug ID 723711: IPsec keys are once again logged when db variable ipsec.debug.logkeys equals 1

Last Modified: Jul 12, 2023

Affected Product(s):
BIG-IP TMOS(all modules)

Known Affected Versions:
13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 13.1.3, 13.1.3.1, 13.1.3.2, 13.1.3.3, 13.1.3.4, 13.1.3.5, 13.1.3.6, 13.1.4, 13.1.4.1, 13.1.5, 13.1.5.1

Fixed In:
14.1.0

Opened: Jun 08, 2018

Severity: 4-Minor

Symptoms

Logging of keys when debug mode was "debug" or higher in IKEv1's /var/log/racoon.log was disabled in an earlier release. IKEv2's logging of keys in other log files was disabled as well.

Impact

Keys, nonces, and several other "sensitive" values are no longer logged for either IKEv1 or IKEv2, making it hard to decrypt test traffic when debugging in the aftermath of problems.

Conditions

-- When negotiating any IKEv1 security association. -- When negotiating any IKEv2 security association when ikedaemon log level has been set to debug or debug2.

Workaround

There is no work around on the BIG-IP. However, debug logs on the remote peer, if not a BIG-IP, may provide the desired key information.

Fix Information

The previous default logging of keys and other values have been restored, if db variable ipsec.debug.logkeys is set equal to one instead of zero. The new default value of ipsec.debug.logkeys is one. But this only logs IKEv2 keys when ikedaemon log level is debug or debug2.

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips