Hi, Implementations can follow this RFC extract to avoid traffic loss. "" Since the initiator sends its Diffie-Hellman value in the IKE_SA_INIT, it must guess the Diffie-Hellman group that the responder will select from its list of supported groups. If the initiator guesses wrong, the responder will respond with a Notify payload of type INVALID_KE_PAYLOAD indicating the selected group. In this case, the initiator MUST retry the IKE_SA_INIT with the corrected Diffie-Hellman group. ""
This point can be followed for CREATE_CHILD_SA exchange also (rekey or child sa creation) to avoid traffic loss. I mean the first rekey will fail (rekey is normally started at some point before the actual lifetime has completely elapsed), so the implementations must retry rekey with the right DH group as per info in the INVALID_KE_PAYLAOD notification. The only problem I see is if the Gw-1 rekeyed with group19 but GW2 does not support Group19 then it can result in traffic loss. For this, the administrators of the two devices must ensure that the other end supports this algorithm before using the same in pfs configuration. Thanks. -----Original Message----- From: IPsec [mailto:[email protected]] On Behalf Of Yoav Nir Sent: Thursday, May 28, 2015 2:58 PM To: IPsecME WG Subject: [IPsec] Question about PFS in IKEv2 Hi This may have been discussed before, but I haven’t found such discussion. Apologies in advance if this is a stupid question. Suppose we have to VPN peers configured to set up a tunnel between them. Suppose further that the IKE SAs are significantly longer-lived than the IPsec SAs. PFS is configured on both sides, but there are no matching groups (perhaps GW-1 is configured with only group 19, while GW-2 is configured only with group 20). When the tunnel is first set up, it is negotiated in the IKE_AUTH exchange. Diffie-Hellman is not performed, so the mismatched configuration is not detected - traffic flows through the tunnel. After a while, one of the gateways attempts to rekey the tunnel, or else create a new tunnel with the same peer. This time the tunnel is set up using the CREATE_CHILD_SA exchange. The SA payload will contain the wrong DH group and the exchange will fail, resulting in traffic flow stopping. As far as I can tell, this behavior is consistent with the RFC, but the user experience is very strange. Traffic should either flow or not flow - it should not stop at rekeying. Am I missing something? Thanks Yoav _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
