Charon refuses to make use of algorithms IDs from the private space
for unknown peer implementations [1]. If you chose to ignore and violate
that section of the RFC since you *know* your peers *must* support those
private IDs, there's no way to disable that behavior.
With this commit a strongswan.conf option is introduced which allows to
deliberately ignore parts of section 3.12 from the standard.
[1] http://tools.ietf.org/html/rfc7296#section-3.12
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
Previously, we simply used the lifetimes of the first
proposal/transform, which is not correct if the initiator uses different
lifetimes in its proposals/transforms.
This avoids having to call strip_dh() in child_cfg_t::get_proposals().
It also inverts the ALLOW_PRIVATE flag (i.e. makes it SKIP_PRIVATE) so
nothing has to be supplied to clone complete proposals.
During proposal selection with ike/child_cfgs a couple of boolean
variables can be set (e.g. private, prefer_self, strip_dh). To simplify
the addition of new parameters, these functions now use a set of flags
instead of indiviual boolean values.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
If CHILD_SAs are created while waiting for the third QM message we'd not
notice the redundancy and updown events would be triggered unevenly.
This is consistent with the behavior on the initiator, which already does
this check right before installation. Moving the existing check is not
possible due to the narrow hook and moving the installation changes which
peer installs the SAs first and could have other side-effects (e.g. in
error or conflict cases). Still, this might result in CHILD_SA state
discrepancies between the two peers.
Fixes#3060.
Although being already logged on level 2, these messages are usually just
confusing if they pop up randomly in the log when e.g. querying the configs
or installing traps. So after this the log messages will only be logged when
actually proposing or selecting traffic selectors during IKE.
If a Quick mode is initiated for a CHILD_SA that is already installed
we can identify this situation and rekey the already installed CHILD_SA.
Otherwise we end up with several CHILD_SAs in state INSTALLED which
means multiple calls of child_updown are done. Unfortunately,
the deduplication code later does not call child_updown() (so up and down
were not even).
Closesstrongswan/strongswan#95.
This way we get the log message in stroke and swanctl as last message
when establishing a connection. It's already like this for the IKE_SA
where IKE_ESTABLISHED is set after the corresponding log message.
Fixes#2364.
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).
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 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.
In some cases the third message of a Quick Mode exchange might arrive
after the first message of a subsequent Quick Mode exchange. Previously
these messages were handled incorrectly and the second Quick Mode
exchange failed.
Some implementations might even try to establish multiple Quick Modes
simultaneously, which is explicitly allowed in RFC 2409. We don't fully
support that, though, in particular in case of retransmits.
Fixes#1076.
This is needed to handle DELETEs properly, which was previously done via
CHILD_REKEYING, which we don't use anymore since 5c6a62ceb6 as it prevents
reauthentication.
As we now use the same reqid for multiple CHILD_SAs with the same selectors,
having marks based on the reqid makes not that much sense anymore. Instead we
use unique marks that use a custom identifier. This identifier is reused during
rekeying, keeping the marks constant for any rule relying on it (for example
installed by updown).
This also simplifies handling of reqid allocation, as we do not have to query
the marks that is not yet assigned for an unknown reqid.
If a peer immediately sends DELETE messages when completing Quick Mode rekeying,
the third Quick Mode message and the DELETE are sent simultaneously. This
implies that DELETE messages may arrive before the completing third Quick Mode
message.
Handle this case by ignoring the DELETE INFORMATIONAL in Quick Mode and let
the delete task handle it.
If PFS is configured for a CHILD_SA first try to create a list of
proposals with using DH group negotiated during phase 1. If the
resulting list is empty (i.e. the DH group(s) configured for PFS differ
from the one(s) configured for the IKE_SA), fall back to the first
configured DH group from the CHILD_SA.
This modificiation is due to the fact that it is likely that the peer
supports the same DH group for PFS it did already for the IKE_SA.
This new flag gives the kernel-interface a hint how it should priorize the
use of newly installed SAs during rekeying.
Consider the following rekey procedure in IKEv2:
Initiator --- Responder
I1 -------CREATE-------> R1
I2 <------CREATE--------
-------DELETE-------> R2
I3 <------DELETE--------
SAs are always handled as pairs, the following happens at the SA level:
* Initiator starts the exchange at I1
* Responder installs new SA pair at R1
* Initiator installs new SA pair at I2
* Responder removes old SA pair at R2
* Initiator removes old SA pair at I3
This makes sure SAs get installed/removed overlapping during rekeying. However,
to avoid any packet loss, it is crucial that the new outbound SA gets
activated at the correct position:
* as exchange initiator, in I2
* as exchange responder, in R2
This should guarantee that we don't use the new outbound SA before the peer
could install its corresponding inbound SA.
The new parameter allows the kernel backend to install the new SA with
appropriate priorities, i.e. it should:
* as exchange inititator, have the new outbound SA installed with higher
priority than the old SA
* as exchange responder, have the new outbound SA installed with lower
priority than the old SA
While we could split up the SA installation at the responder, this approach
has another advantage: it allows the kernel backend to switch SAs based on
other criteria, for example when receiving traffic on the new inbound SA.
Tobias Brunner