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.
TKM can't verify such signatures so we'd fail in the authorize hook.
Skipping the algorithm identifier doesn't help if the peer uses
anything other than SHA-1, so config changes would be required.
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).
Martin Willi