In addition that it may reduce memory usage and improve performance for large
responses, it returns immediate results. This is important for longer lasting
commands, such as initiate/terminate, where immediate log feedback is preferable
when interactively calling such commands.
To simplify handling of authentication rounds in dictionaries/hashtables on the
client side, we assign unique names to each authentication round when listing
connection.
An uninstall target is currently not supported, as there is no trivial way with
either plain setuptools or with easy_install. pip would probably be the best
choice, but we currently don't depend on it.
IKE is very strict in the length of KE payloads, and it should be safe to
strictly verify their length. Not doing so is no direct threat, but allows DDoS
amplification by sending short KE payloads for large groups using the target
as the source address.
If additional tasks get queued before/while rekeying an IKE_SA, these get
migrated to the new IKE_SA. We previously did not trigger initiation of these
tasks, though, leaving the task unexecuted until a new task gets queued.
As the startup timestamp needs 10 characters, we only have left 4 characters
for the IKE_SA unique identifier. This is insufficient when having 10000 IKE_SAs
or more established, resulting in non-unique session identifiers.
Fixes#889.
We are actually not in rekeying state, but just trigger a separate, new IKE_SA
as a replacement for the current IKE_SA. Switching to the REKEYING state
disables the invocation of both IKE and CHILD_SA updown hooks as initiator,
preventing the removal of any firewall rules.
Fixes#885.
While a passively installed IKE_SA does not queue a DPD timeout job, one that
switches from active to passive might execute it. Ignore such a queued job if
the IKE_SA is in passive state.
The current "inbound" flag is used for two purposes: To define the actual
direction of the SA, but also to determine the operation used for SA
installation. If an SPI has been allocated, an update operation is required
instead of an add.
While the inbound flag normally defines the kind of operation required, this
is not necessarily true in all cases. On the HA passive node, we install inbound
SAs without prior SPI allocation.
While the the meaning of the "inbound" flag on the kernel_interface->add_sa()
call is not very clear, we still need that update logic to allow installation of
inbound SAs without SPI allocation. This is used in the HA plugin as a passive
node.
This reverts commit 698ed656.
While this change results in the correct add/update flag during installation,
it exchanges all other values in the child_sa->install() call. We should pass
the correct flag, but determine the add/update flag by other means.
This reverts commit e722ee5d.
Previously, we failed without recovery if a private key did not support
a selected signature scheme (based on key strength and the other peer's
supported hash algorithms).
Especially callback jobs might refer to memory that gets invalid after
the plugins got unlaoded, so make sure we destroy these jobs before.
References #840.
The payload we sent before is not compliant with RFC 2407 and thus some
peers might abort negotiation (e.g. with an INVALID-PROTOCOL-ID error).
Fixes#819.
If this is disabled the schemes configured in `rightauth` are only
checked against signature schemes used in the certificate chain and
signature schemes used during IKEv2 are ignored.
Disabling this could be helpful if existing connections with peers that
don't support RFC 7427 use signature schemes in `rightauth` to verify
certificate chains.
This enables late connection switching based on the signature scheme used
for IKEv2 and allows to enforce stronger signature schemes.
This may break existing connections with peers that don't support RFC 7427
if signature schemes are currently used in `rightauth` for certificate chain
validation and if the configured schemes are stronger than the default used
for IKE (e.g. SHA-1 for RSA).
We use the new signature authentication instead for this. This is not
backward compatible but we only released one version with BLISS support,
and the key format will change anyway with the next release.
Martin Willi