If a specified SPI is not zero, tell the kernel to use the SPI by using
SADB_EXT_SPIRANGE. Otherwise, the kernel picks a random SPI.
It enables to mimic racoon.
Current racoon code cannot detect duplicate last fragments as it uses
the fragment flag instead of the fragment number.
The code does not consider that the IKE payload fragments might not be
received in the correct order. In this case, packet complete detection
will again fail and VPN clients abandoned from VPN service.
Nevertheless, clients still can add fragments to the fragment queue and
fill it up to the possible 255 fragments. Only duplicates are detected,
but not the fragments with a number greater than the last fragment
number.
The last fragment number is kept in the Phase 1 handler
after fragment queue deletion, which may lead to error notifications
after succesful reassembly of the IKE phase 1 message.
In general, the 2017's CVE fix added laconic and difficult to understand
failure notifications, which do not much help for analysis, why a VPN
client was blocked by racoon server.
This patch fixes the code and aligns it to Microsoft/Cisco IKE
fragmentation specification. It provides error logging which is in line
with above specification and adds some debug info to the logs to better
support analysis VPN client blackballing.
XXX: pullup-8
fragment list check.
While the fix in https://launchpad.net/~rdratlos/+archive/ubuntu/racoon
- if (i > last_frag) /* It is complete */
+ if (i >= last_frag) /* It is complete */
has the correct behavior, it violates the test for successful
completion of the invariant of the loop:
for (i = 1; i <= last_frag; i++) {
if (!check_fragment_index())
break;
}
if (i > last_frag)
return ok;
It is better to move the check for NULL in the loop earlier, so that
the final iteration is done and the test is kept the same. It makes
the code easier to understand and preserves the original intent.
XXX: pullup-8
what's going on.
We have now become "upstream", and most of the ipsec-tools development is
done in NetBSD's CVS. However, many distributions still take their
tarballs from SourceForge (which is defunct, and not maintained).
Updating an SA (SADB_UPDATE) requires that a process issuing
SADB_UPDATE is the same as a process issued SADB_ADD (or SADB_GETSPI).
This means that update command must be used with add command in a
configuration of setkey. This usage is normally meaningless but
useful for testing (and debugging) purposes.
