5.223. openswan

Bug Fix

BZ#852454

When a tunnel was established between two IPsec hosts (say host1 and host2) utilizing DPD (Dead Peer Detection), and if host2 went offline while host1 continued to transmit data, host1 continually queued multiple phase 2 requests after the DPD action. When host2 came back online, the stack of pending phase 2 requests was established, leaving a new IPsec SA (Security Association), and a large group of extra SA's that consumed system resources and eventually expired. This update ensures that openswan has just a single pending phase 2 request during the time that host2 is down, and when host2 comes back up, only a single new IPsec SA is established, thus preventing this bug.

Bug Fixes

BZ#834660

According to the RFC 5996 standard, reserved fields must be ignored on receipt irrespective of their value. Previously, however, the contents of the reserved fields was not being ignored on receipt for some payloads. Consequently, Openswan reported an error message and IKE negotiation failed. With this update, Openswan has been modified to ignore the reserved fields and IKE negotiation succeeds regardless of the reserved field value.

BZ#834662

When a connection was configured in transport mode, Openswan did not pass information about traffic selectors to the NETKEY/XFRM IPsec kernel stack during the setup of security associations (SAs). Consequently, the information was not available in the output of the "ip xfrm state" command. With this update, Openswan correctly passes the traffic selectors information to the kernel when SAs are setup in transport mode.

Bug Fixes

BZ#768162

Previously, Openswan sometimes generated a KE payload that was 1 byte shorter than specified by the Diffie-Hellman algorithm. Consequently, IKE renegotiation failed at random intervals. An error message in the following format was logged:

next payload type of ISAKMP Identification Payload has an unknown value:

This update checks the length of the generated key and if it is shorter than required, leading zero bytes are added.

BZ#768442

Older versions of kernel required the output length of the HMAC hash function to be truncated to 96 bits, therefore Openswan previously worked with 96-bit truncation length when using the HMAC-SHA2-256 algorithm. However, newer kernels require the 128-bit HMAC truncation length, which is as per the RFC4868 specification. Consequently, this difference could cause incompatible SAs to be set on IKE endpoints due to one endpoint using 96-bit and the other 128-bit output length of the hash function. This update modifies the underlying code so that Openswan now complies with RFC4868 and adds support for the new kernel configuration parameter, sha2_truncbug. If the sha2_truncbug parameter is set to yes, Openswan now passes the correct key length to the kernel, which ensures interoperability between older and newer kernels.

BZ#771457

When processing an IKE_SA_INIT exchange and the RESERVED field of the IKE_SA_INIT request or response messages was modified, Openswan did not ignore the field as expected according to the IKEv2 RFC5996 specification. Consequently, IKE_SA_INIT messages with reserved fields set were processed as erroneous messages by Openswan and the IKE_SA_INIT exchange failed. With this update, Openswan has been modified to ignore reserved fields as expected and IKE_SA_INIT exchanges succeed in this scenario.

BZ#771460

When processing an IKE_AUTH exchange and the RESERVED field of the IKE_AUTH request or response messages was modified, Openswan did not ignore the field as expected according to the IKEv2 RFC5996 specification. Consequently, the IKE_AUTH messages were processed as erroneous messages by Openswan and the IKE_AUTH exchange failed. With this update, Openswan has been modified to ignore reserved fields as expected and IKE_AUTH exchanges succeed in this scenario.

BZ#771461

Openswan incorrectly processed traffic selector messages proposed by the responder (the endpoint responding to an initiated exchange) by failing to confine them to a subset of the initially proposed traffic selectors. As a consequence, Openswan set up CHILD security associations (SAs) incorrectly. With this update, Openswan reduces the set of traffic selectors correctly, and sets up IKE CHILD SAs accordingly.

BZ#771463

Previously, Openswan did not behave in accordance with the IKEv2 RFC5996 specification and ignored IKE_AUTH messages that contained an unrecognized “Notify” payload. This resulted in IKE SAs being set up successfully. With this update, Openswan processes any unrecognized Notify payload as an error and IKE SA setup fails as expected.

BZ#771464

When processing an INFORMATIONAL exchange, the responder previously did not send an INFORMATIONAL response message as expected in reaction to the INFORMATIONAL request message sent by the initiator. As a consequence, the INFORMATIONAL exchange failed. This update corrects Openswan so that the responder now sends an INFORMATIONAL response message after every INFORMATIONAL request message received, and the INFORMATIONAL exchange succeeds as expected in this scenario.

BZ#771465

When processing an INFORMATIONAL exchange with a Delete payload, the responder previously did not send an INFORMATIONAL response message as expected in reaction to the INFORMATIONAL request message sent by the initiator. As a consequence, the INFORMATIONAL exchange failed and the initiator did not delete IKE SAs. This updates corrects Openswan so that the responder now sends an INFORMATIONAL response message and the initiator deletes IKE SAs as expected in this scenario.

BZ#771466

When the responder received an INFORMATIONAL request with a “Delete” payload for a CHILD SA, Openswan did not process the request correctly and did not send the INFORMATIONAL response message to the initiator as expected according to the RFC5996 specification. Consequently, the responder was not aware of the request and only the initiator's CHILD SA was deleted. With this update, Openswan sends the response message as expected and the CHILD SA is deleted properly on both endpoints.

BZ#771467

Openswan did not ignore the minor version number of the IKE_SA_INIT request messages as required by the RFC5996 specification. Consequently, if the minor version number of the request was higher than the minor version number of the IKE protocol used by the receiving peer, Openswan processed the IKE_SA_INIT messages as erroneous and the IKE_SA_INIT exchange failed. With this update, Openswan has been modified to ignore the Minor Version fields of the IKE_SA_INIT requests as expected and the IKE_SA_INIT exchange succeeds in this scenario.

BZ#771470

The Openswan IKEv2 implementation did not correctly process an IKE_SA_INIT message containing an INVALID_KE_PAYLOAD “Notify” payload. With this fix, Openswan now sends the INVALID_KE_PAYLOAD notify message back to the peer so that IKE_SA_INIT can restart with the correct KE payload.

BZ#771472

Openswan incorrectly processed traffic selector messages proposed by the initiator (the endpoint which started an exchange) by failing to confine them to a subset of the initially proposed traffic selectors. As a consequence, Openswan set up CHILD SAs incorrectly. With this update, Openswan reduces the set of traffic selectors correctly, and sets up IKE CHILD SAs accordingly.

BZ#771473

Previously, Openswan did not respond to INFORMATIONAL requests with no payloads that are used for dead-peer detection. Consequently, the initiator considered the responder to be a dead peer and deleted the respective IKE SAs. This update modifies Openswan so that an empty INFORMATIONAL response message is now sent to the initiator as expected, and the initiator no longer incorrectly deletes IKE SAs in this scenario.

BZ#771475

When processing an INFORMATIONAL exchange and the RESERVED field of the INFORMATIONAL request or response messages was modified, Openswan did not ignore the field as expected according to the IKEv2 RFC5996 specification. Consequently, the INFORMATIONAL messages were processed as erroneous by Openswan, and the INFORMATIONAL exchange failed. With this update, Openswan has been modified to ignore reserved fields as expected and INFORMATIONAL exchanges succeed in this scenario.

BZ#795842

When the initiator received an INFORMATIONAL request with a “Delete” payload for an IKE SA, Openswan did not process the request correctly and did not send the INFORMATIONAL response message to the responder as expected according to the RFC5996 specification. Consequently, the initiator was not aware of the request and only the responder's IKE SA was deleted. With this update, Openswan sends the response message as expected and the IKE SA is deleted properly on both endpoints.

BZ#795850

IKEv2 requires each IKE message to have a sequence number for matching a request and response when re-transmitting the message during the IKE exchange. Previously, Openswan incremented sequence numbers incorrectly so that IKE messages were processed in the wrong order. As a consequence, any messages sent by the responder were not processed correctly and any subsequent exchange failed. This update modifies Openswan to increment sequence numbers in accordance with the RFC5996 specification so that IKE messages are matched correctly and exchanges succeed as expected in this scenario.

Bug Fix

BZ#983451

The openswan package for Internet Protocol Security (IPsec) contains two diagnostic commands, "ipsec barf" and "ipsec look", that can cause the iptables kernel modules for NAT and IP connection tracking to be loaded. On very busy systems, loading such kernel modules can result in severely degraded performance or lead to a crash when the kernel runs out of resources. With this update, the diagnostic commands do not cause loading of the NAT and IP connection tracking modules. This update does not affect systems that already use IP connection tracking or NAT as the iptables and ip6tables services will already have loaded these kernel modules.