Some tasks might get removed immediately once the IKE_SA_INIT response has
been handled even if there were notifies that require a restart of the
IKE_SA (e.g. COOKIE or INVALID_KE_PAYLOAD). Such a task is ike_vendor,
which caused vendor IDs not to get sent in a retry. This change ensures
all required tasks are queued after the reset, which some callers did
already anyway.
These seem to indicate the major and minor version of the protocol, like
e.g. for the DPD vendor ID. Some implementations seem to send versions
other than 1.0 so we just ignore these for now when checking for known
vendor IDs.
Fixes#2088.
By aborting the active task we don't have to wait for potential
retransmits if the other peer does not respond to the current task.
Since IKEv1 has no sequential message IDs and INFORMATIONALs are no real
exchanges this should not be a problem.
Fixes#1537
References #429, #1410Closesstrongswan/strongswan#48
Depending on the lifetimes a CHILD_SA we rekeyed as responder might
expire shortly afterwards. We don't want to rekey it again.
When retrying due to an INVALID_KE_PAYLOAD notify the expected state
is CHILD_REKEYING if it is anything else (e.g. due to a collision) we
ignore it.
We also abort the exchange properly if we don't find the CHILD_SA, no
need for an empty INFORMATIONAL exchange anymore.
If a passive rekeying fails due to an INVALID_KE_PAYLOAD we don't want
to consider this task later when resolving collisions. This previously
might have caused the wrong SA to get deleted/installed based on the nonces
in the unsuccessful exchange.
Such a task is not initiated unless a certain time has passed. This
allows delaying certain tasks but avoids problems if we'd do this
via a scheduled job (e.g. if the IKE_SA is rekeyed in the meantime).
If the IKE_SA is rekeyed the delay of such tasks is reset when the
tasks are adopted i.e. they get executed immediately on the new IKE_SA.
This hasn't been implemented for IKEv1 yet.
If the peer does not detect the rekey collision and deletes the old
IKE_SA and then receives the colliding rekey request it will respond with
TEMPORARY_FAILURE. That notify may arrive before the DELETE does, in
which case we may just conclude the rekeying initiated by the peer.
Also, since the IKE_SA is destroyed in any case when we receive a delete
there is no point in storing the delete task in collide() as process_i()
in the ike-rekey task will never be called.
We conclude the rekeying before deleting the IKE_SA. Waiting for the
potential TEMPORARY_FAILURE notify is no good because if that response
does not reach us the peer will not retransmit it upon our retransmits
of the rekey request if it already deleted the IKE_SA after receiving
our response to the delete.
This makes handling such IKE_SAs more specifically compared to keeping them
in state IKE_CONNECTING or IKE_ESTABLISHED (which we did when we lost a
collision - even triggering the ike_updown event), or using IKE_REKEYING for
them, which would also be ambiguous.
For instance, we can now reject anything but DELETES for such SAs.
Moving to the new SA only after receiving the DELETE for the old SA was
not ideal as it rendered the new SA unusable (because it simply didn't
exist in the manager) if the DELETE was delayed/got dropped.
This happens if the peer deletes the redundant SA before we are able to
handle the response. The deleted SA will be in state CHILD_INSTALLED but
we don't want to trigger the child_updown() event for it or recreate it.
Generally, we will not find the CHILD_SA by searching for it with the
outbound SPI (the initiator of the DELETE sent its inbound SPI) - and if
we found a CHILD_SA it would most likely be the wrong one (one in which
we used the same inbound SPI as the peer used for the one it deletes).
And we don't actually want to destroy the CHILD_SA at this point as we
know we already initiated a DELETE ourselves, which means that task
still has a reference to it and will destroy the CHILD_SA when it
receives the response from the other peer.
If two CHILD_SAs with mark=%unique are created concurrently they could
otherwise end up with either the same mark or different marks in both
directions.
This is the case for the IKE_SA_INIT and the initial IKEv1 messages, which
are pre-generated in tasks as at least parts of it are used to generate
the AUTH payload. The IKE_SA_INIT message will never be fragmented, but
the IKEv1 messages might be, so we can't just call generate_message().
Fixes#1478.
Some peers send an INITIAL_CONTACT notify after they received our XAuth
username. The XAuth task waiting for the third XAuth message handles
this incorrectly and closes the IKE_SA as no configuration payloads are
contained in the message. We queue the INFORMATIONAL until the XAuth
exchange is complete to avoid this issue.
Fixes#1434.
This provides a fix if symmetrically overlapping policies are
installed as e.g. the case in the ikev2/ip-two-pools-db scenario:
carol 10.3.0.1/32 ----- 10.3.0.0/16, 10.4.0.0/16 moon
alice 10.4.0.1/32 ----- 10.3.0.0/16, 10.4.0.0/16 moon
Among others, the following FWD policies are installed on moon:
src 10.3.0.1/32 dst 10.4.0.0/16
...
tmpl ...
src 10.4.0.0/16 dst 10.3.0.1/32
...
src 10.4.0.1/32 dst 10.3.0.0/16
...
tmpl ...
src 10.3.0.0/16 dst 10.4.0.1/32
...
Because the network prefixes are the same for all of these they all have the
same priority. Due to that it depends on the install order which policy gets
used. For instance, a packet from 10.3.0.1 to 10.4.0.1 will match the
first as well as the last policy. However, when handling the inbound
packet we have to use the first one as the packet will otherwise be
dropped due to a template mismatch. And we can't install templates with
the "outbound" FWD policies as that would prevent using different
IPsec modes or e.g. IPComp on only one of multiple SAs.
Instead we install the "outbound" FWD policies with a lower priority
than the "inbound" FWD policies so the latter are preferred. But we use
a higher priority than default drop policies would use (in case they'd
be defined with the same subnets).
If there is currently no route to reach the other peer we just default
to left=%any. The local address is only really used to resolve
leftsubnet=%dynamic anyway (and perhaps for MIPv6 proxy transport mode).
Fixes#1375.
An old (already rekeyed) CHILD_SA would get switched back into CHILD_REKEYING
state. And we actually want to change the currently installed CHILD_SA to
that state and later CHILD_REKEYED and properly call e.g. child_rekey() and
not do this again with an old CHILD_SA. Instead let's only check installed
or currently rekeying CHILD_SAs (in case of a rekey collision). It's also
uncommon that there is a CHILD_SA in state CHILD_REKEYED but none in state
CHILD_INSTALLED or CHILD_REKEYING, which could happen if e.g. a peer deleted
and recreated a CHILD_SA after a rekeying. But in that case we don't want
to treat the new CHILD_SA as rekeying (e.g. in regards to events on the bus).
Tobias Brunner