Project

General

Profile

Bug #1131

Content of NAT_DETECTION_SOURCE_IP is changed in retransmissions

Added by Valery Smyslov over 3 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Category:
libcharon
Target version:
Start date:
25.09.2015
Due date:
Estimated time:
Affected version:
5.3.3
Resolution:
Fixed

Description

The following behaviour was observed with strongSwan for Android 1.5.0 (from PlayMarket, daemon 5.3.3) on lossy networks.

Sometimes the VPN connection using IKEv2 with Security Gateway cannot be set with the diagnostic message on SGW - "Invalid signature". Usually the subsequent attempt is successful. The investigations revealed, that when strongSwan performs retransmissions of IKE_SA_INIT messages due to packets loss, it sometimes changes the content of NAT_DETECTION_SOURCE_IP Notification, although the source IP and Port (as well as IKE SPI) remain the same. Depending on which of retransmissions reaches responder, the input to InitiatorSignedOctets (Section 2.15 of RFC7296) is different and the signature validation could fail.

This behaviour was only observed on Android.

Here is the strongSwan log and the corresponding wireshark transcript recorded on SGW (note that SGW address is mangled for privacy reasons).
Description of the transcript:
1. Line 1 - the first IKE_SA_INIT message from strongSwan. NAT_DETECTION_SOURCE_IP contains 423bd2896eb49250ccf8da5e77bfd550948f8ff2 (Line 570)
2. Line 597 - response from SGW, with INVALID_KE_PAYLOAD (seems to get lost)
3. Line 683 - strongSwan resends the first message intact. NAT_DETECTION_SOURCE_IP still contains 423bd2896eb49250ccf8da5e77bfd550948f8ff2 (Line 1250)
4. Line 1276 - again response from SGW, with INVALID_KE_PAYLOAD
5. Line 1362 - strongSwan receives message from SGW and resends its original request wih new KE Payload. But at the same time it changes the content of NAT_DETECTION_SOURCE_IP to 7422b95a724fd9959a00269ebe0635a47682a2f4 (Line 1929), although neither source IP, nor source Port, nor IKE SPIs are changed.
6. Line 1955 - SGW responds to previous message, but his respons seems to get lost
7. Line 2124 - strongSwan retransmits its last message again, and again changing NAT_DETECTION_SOURCE_IP now to 268ee601736293f67fa5582c4a5985759d9d8b78 (Line 2691).
8. Line 2717 - SGW retransmits its response
9. Line 2886, 2964 - strongSwan receives response from SGW and initiates IKE_AUTH exchange sending 2 fragments
10. Line 3042 - SGW reports of failed authentication

charon.log (3.98 KB) charon.log strongSwan log Valery Smyslov, 25.09.2015 17:30
fail.txt (150 KB) fail.txt wireshark transcript of session Valery Smyslov, 25.09.2015 17:31

Associated revisions

Revision 8484d2b0 (diff)
Added by Tobias Brunner over 3 years ago

ike-natd: Create fake NAT-D payloads in a more static way

In some scenarios an IKE_SA might get restarted multiple times (e.g.
due to retransmits and delayed INVALID_KE_PAYLOAD notifies) so that
two IKE_SA_INIT messages might be sent that only differ in the
previously randomly generated NAT_DETECTION_SOURCE_IP payload.
This could cause an authentication failure on the responder if the two
peers don't use the same IKE_SA_INIT message in their InitiatorSignedOctets.

While the payload is generated in a reproducible way it will still change
when the daemon is restarted, which should make detecting the payloads
as fake a bit harder (compared to e.g. just using 0.0.0.0:0 as address).

Fixes #1131.

History

#1 Updated by Tobias Brunner over 3 years ago

  • Tracker changed from Issue to Bug
  • Description updated (diff)
  • Status changed from New to Feedback

The Android client uses force_encaps=yes to force UDP encapsulation (since the userland client can only send UDP packets). This is done by faking NAT-D payloads, that is, the NAT_DETECTION_SOURCE_IP payload is just filled with random data.

5. Line 1362 - strongSwan receives message from SGW and resends its original request wih new KE Payload. But at the same time it changes the content of NAT_DETECTION_SOURCE_IP to 7422b95a724fd9959a00269ebe0635a47682a2f4 (Line 1929), although neither source IP, nor source Port, nor IKE SPIs are changed.

An INVALID_KE_PAYLOAD will cause the IKE_SA to get reset, which means that in the second attempt (after the actual retransmit and the received INVALID_KE_PAYLOAD notify) the NAT_DETECTION_SOURCE_IP payload will get filled with new random data. It will also contain a new DH public value in the KE payload as the DH group changed.

7. Line 2124 - strongSwan retransmits its last message again, and again changing NAT_DETECTION_SOURCE_IP now to 268ee601736293f67fa5582c4a5985759d9d8b78 (Line 2691).

Again, this is not really a retransmit, but comes after a reset of the IKE_SA due to the delayed second INVALID_KE_PAYLOAD notify. However, because the DH group did not change (charon already switched to 1536 bits) no new DH public value is sent.

10. Line 3042 - SGW reports of failed authentication

What's interesting is that because the DH group did not change (due to this unfortunate sequence of delayed messages) charon uses the same public value for both requests, so the only thing changing here really is the NAT-D payload. If the DH value also changed the SGW would not be able to decrypt the IKE_AUTH message as both peers would derive the IKE keys from different DH values.

There are two options to avoid this:

1. Cache the generated random NAT-D value and reuse it.
2. Don't generate these values randomly but base them on a static value that will not represent a client's actual IP address and port (e.g. use 0.0.0.0:0/[::]:0).

Both would require client changes. I pushed an implementation of the second approach to the 1131-fake-nat-d-static branch (not tested yet).

As a workaround you could change the server's IKE proposal to modp2048 to avoid the unnecessary additional IKE_SA_INIT exchange in the first place.

#2 Updated by Tobias Brunner over 3 years ago

  • Category set to libcharon
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Target version set to 5.3.4
  • Resolution set to Fixed

Fixed with the associated commit.

Also available in: Atom PDF