Is there any situation in the Libreswan IKE implementation in which the third packet of an Aggressive Exchange is allowed to *not* be encrypted? RFC 2408 (https://tools.ietf.org/html/rfc2408#section-4.7) seems to say no:
“In the third (3) message, the initiator transmits the results of the agreed upon authentication function. This information is transmitted under the protection of the common shared secret. Local security policy dictates the action if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange.” I’m comparing IKE packet dumps from two similar IPsec peer configurations: a proprietary embedded device and Libreswan, and the same device with a Cisco IOS device. NAT traversal is in use in both situations (Libreswan and the Cisco are behind NAT), and the embedded device is always the session initiator. The third packet contains two NAT-D payloads and a Hash payload. With the Cisco, the IKE SA and tunnel establishes, even though the third Aggressive Exchange packet from the embedded device to the Cisco is *not* encrypted. Libreswan terminates the Aggressive Exchange with an Informational message with INVALID-FLAGS notification and a log message indicating it expected an encrypted response, which seems correct according to the RFC and because the Flags field of the third packet is set to 0x00. So even though an IPsec tunnel “works” between the device and the Cisco, and not with Libreswan, it appears like it might be buggy behavior from both: the device should encrypt the third packet, and the Cisco should reject it. Can anybody on the development team confirm that the third packet in Aggressive mode must always be encrypted? Thanks.
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
