Bug ID 718397: IKEv2: racoon2 appends spurious trailing null byte to ID payloads

Last Modified: Sep 13, 2023

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

Known Affected Versions:
11.6.0, 11.6.1, 11.6.2, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 12.0.0, 12.0.0 HF1, 12.1.0 HF1, 12.0.0 HF2, 12.1.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2, 12.1.0, 12.1.1, 12.1.2, 12.1.3, 12.1.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6, 12.1.3.7, 12.1.4, 12.1.4.1, 12.1.5, 12.1.5.1, 12.1.5.2, 12.1.5.3, 12.1.6, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 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, 14.0.0, 14.0.0.1, 14.0.0.2, 14.0.0.3, 14.0.0.4

Fixed In:
14.1.0, 14.0.0.5, 13.1.1.4

Opened: May 03, 2018

Severity: 3-Major

Symptoms

IPsec clients implementing RFC5996 correctly cannot interoperate with the BIG-IP system when the peers-id-type is anything other than address, because racoon2 inside BIG-IP appends a null byte to any string-based ID type (for both peers_id and my_id). This makes the IKE_AUTH exchange fail, usually because the ID_I from the initiator cannot match the peers-id-value in config for that ike-peer, because there is a one-byte difference between the compared strings.

Impact

IKE negotiation fails during the second IKE_AUTH exchange of messages, preventing any tunnel from being established. Outage with a non-BIG-IP client is permanent until the config is changed to use peers-id-type=address.

Conditions

When any non-BIG-IP client initiates an IKE negotiation using any id-type that is not IPv4 or IPv6. In particular, fqdn and asn1dn for peers-id-type in local BIG-IP configurations.

Workaround

Use peers-id-type=address to interoperate with non-BIG-IP clients for IPsec.

Fix Information

Because RFC5996 forbids trailing null bytes in ID payloads, the BIG-IP software was actually not compliant with the RFC by encoding payloads this way itself. It only worked because both initiator and responder did the same thing. Now the BIG-IP software does not add the extra trailing null byte into ID payloads and local ID values, so the BIG-IP system can accept IKE_AUTH messages from non-BIG-IP clients. Note: this fix creates an incompatibility with previous BIG-IP version when peers-id-type is any other type than address.

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips