This is particularly important for higher number of segments, but even
with small numbers there is a significant difference. For instance,
with 4 segments the fourth segment had no IPs assigned with the old
code, no matter how large the pool, because none of the eight bits used
for the segment check hashed/mapped to it.
Reqids for the same traffic selectors are now stable so we don't have to
pass reqids of previously installed CHILD_SAs. Likewise, we don't need
to know the reqid of the newly installed trap policy as we now uninstall
by name.
With IKEv1 we transmit both public DH factors (used to derive the initial
IV) besides the shared secret. So these messages could get significantly
larger than 1024 bytes, depending on the DH group (modp2048 just about
fits into it). The new default of 2048 bytes should be fine up to modp4096
and for larger groups the buffer size may be increased (an error is
logged should this happen).
To handle Phase 2 exchanges on the other HA host we need to sync the last
block of the last Phase 1 message (or the last expected IV). If the
gateway is the initiator of a Main Mode SA the last message is an
inbound message. When handling such messages the expected IV is not
updated until it is successfully decrypted so we can't sync the IV
when processing the still encrypted (!plain) message. However, as responder,
i.e. if the last message is an outbound message, the reverse applies, that
is, we get the next IV after successfully encrypting the message, not
while handling the plain message.
Fixes#1267.
It is required for IKEv1 to determine the DH group of the CHILD SAs
during rekeying. It also fixes the status output for HA SAs, which so
far haven't shown the DH group on the passive side.
Fixes#1267.
This may happen if something like `echo ... > /path/to/fifo` is used
before the plugin was able to create the FIFO. In that case we'd end
up in a loop always reading the same values from the static file.
If AEAD algorithms are used no integrity algorithm will be received from
the other HA node. But since AUTH_UNDEFINED is 1024 and not 0 this value
was incorrectly added to the proposal, resulting in a failure during key
derivation. The variables are now explicitly initialized to 0, as already
was the case for the IKE SAs.
Fixes#1051.
When the IKE_SA is synced without the remote address, after a
reauthentication charon is not able to find it in its connected_peers
table since the destination host will be %any (it's missing in the
message, hence the default from the newly created ike_sa_t -- %any --
will be used).
By adding the value to the HA_IKE_ADD message, we should be able to
solve this problem.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
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.
The inbound flag is used to determine if we have to install an update or a new
SA in the kernel. As we do not have allocated SPIs and therefore can't update
an existing SA in the HA plugin, always set the flag to FALSE.
Before 698ed656 we had extra logic for that case, but handling it directly in
the HA plugin is simpler.
Tobias Brunner