According to the mode-config draft there is no prefix sent for
IPv6 addresses in IKEv1. We still accept 17 bytes long addresses for
backwards compatibility with older strongSwan releases.
Fixes#1304.
When charon rekeys a CHILD_SA after a soft limit expired, it is only
deleted after the hard limit is reached. In case of packet/byte limits
this may not be the case for a long time since the packets/bytes are
usually sent using the new SA. This may result in a very large number of
stale CHILD_SAs and kernel states. With enough connections configured this
will ultimately exhaust the memory of the system.
This patch adds a strongswan.conf setting that, if enabled, causes the old
CHILD_SA to be deleted by the initiator after a successful rekeying.
Enabling this setting might create problems with implementations that
continue to use rekeyed SAs (e.g. if the DELETE notify is lost).
If it was necessary to pass the local certificates we could probably
clone the config (but we don't do that either when later looking for the
key to actually authenticate).
Passing auth adds the same subject cert to the config over and over
again (I guess we could also try to prevent that by searching for
duplicates).
If there is no path to the other peer there is no point in trying to
send a NAT keepalive.
If the condition changes back and forth within the keepalive interval there
is a chance that multiple jobs get queued.
This could be helpful when debugging deadlocks that manifest around
wait_for_entry(), as it helps identifying other involved threads (the
thread object is seen in the thread_main() call in each thread's backtrace).
With IKEv1 we have to reuse IKE_SAs as otherwise the responder might
detect the new SA as reauthentication and will "adopt" the CHILD_SAs of
the original IKE_SA, while the initiator will not do so. This could
cause CHILD_SA rekeying to fail later.
Fixes#1236.
When handling a rekey collision we might have to delete an already
installed redundant CHILD_SA (or expect the other peer to do so).
We don't want to trigger updown events for these as neither do we do
so for successfully rekeyed CHILD_SAs.
Fixes#853.
If the retransmit of an initial message is processed concurrently with the
original message it might not have been handled as intended as the
thread processing the retransmit might not have seen the correct value
of entry->processing set by the thread handling the original request.
For IKEv1, i.e. without proper message IDs, there might still be races e.g.
when receiving a retransmit of the initial IKE message while processing the
initiator's second request.
Fixes#1269.
If we mistakenly detect a new IKE_SA as a reauthentication the client
won't request the previous virtual IP, but since we already migrated
it we already triggered the assign_vips() hook, so we should reassign
the migrated virtual IP.
Fixes#1152.
We already did so during Phase 1 but because all three Quick Mode
message have the same message ID we occasionally dropped the third
message as retransmit, so we do it there too. For INFORMATIONAL
and TRANSACTION exchanges we don't expect more than one inbound message
with the same message ID so we still use them there.
Fixes#1198.
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.
In some cases we call wait_for_entry() but don't actually check out the
entry afterwards (e.g. because it doesn't match certain criteria). So
there won't be a call to checkin() for such entries causing waiting
threads to get signaled. Instead, such threads would be blocked until
another thread properly checks out/in the entry (or does a blocking
enumeration).
If we haven't received the third QM message for multiple exchanges the
return value of NEED_MORE for passive tasks that are not responsible for
a specific exchange would trigger a fourth empty QM message.
Fixes: 4de361d92c ("ikev1: Fix handling of overlapping Quick Mode exchanges")
References #1076.
Previously, the current segment was held while checking for duplicate
SAs, which requires acquiring all segments. If multiple threads did this
concurrently this resulted in a deadlock as they couldn't acquire the
segments held by the other threads attempting to do the same. With the
default configuration only one segment is used, which prevents the problem
as only one thread can check in an IKE SA concurrently.
Fixes: a064eaa8a6 ("Handling of initial contact")
left|rightsubnet default to %dynamic, which is basically 0.0.0.0/0 until an
address is assigned to it. So if only one side was undefined and the other
traffic selector was IPv6 an address family mismatch would occur.
References #595.
When retrying due to a DH group mismatch this is already done by the
child-create task itself. And in other cases where the task returns
NEED_MORE we actually will need access to a possible proposal to properly
delete it.
Tobias Brunner