Wireshark doesn't really support it, but this way it at least decodes
the ESP packets correctly and the encryption keys are saved and the
packets can be decrypted. The full-length versions of SHA-384 and
SHA-512 are not supported by Wireshark as 256-bit is the longest ICV
it is able to decode currently.
The job is queued properly, yet the timing information is wrong.
Signed-off-by: Stefan Berghofer <stefan.berghofer@secunet.com>
Fixes: ee61471113 ("implemented RFC4478 (repeated authentication)...")
If the reauthentication is scheduled while rekeying, the difference
might be negative, however, schedule_job() takes an unsigned int,
so the reauth would get scheduled very far in the future.
If rekeying and reauthetication coincided, the reauth job could get
scheduled to run immediately i.e. before checkin() was called. So the
new IKE_SA would not get reauthenticated, however, the further delayed
delete job would later find the new IKE_SA and delete it.
This way, jobs for new IKE_SAs (created via create_new()) may be
scheduled/queued before checkin() is called. If they run before
that happens, they will now correctly block in checkout() instead of
doing nothing because the IKE_SA was not found.
We don't actually check that SA out (i.e. it's not registered with the
manager). That was originally different but had to be changed with
86993d6b90 to avoid that SAs created for rekeying don't block other
threads on the manager.
These changes should ensure that concurrent calls to checkout_by_config()
result in a single IKE_SA. For instance, when acquires for different
children of the same connection are triggered concurrently.
There are two major changes to the interface:
1) The peer config object is now always set on the returned IKE_SA.
That was previously only the case if an existing IKE_SA was
returned.
2) The IKE_SA is now always registered with the manager and properly
checked out, which also was only the case for existing IKE_SAs
before.
TLS 1.3 uses HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
as defined in RFC 5869 to compute traffic secrets.
Co-authored-by: bytinbit <meline.sieber@hsr.ch>
The key material, in particular the nonce/IV, is derived differently and
the IV is also generated in a different way. Additionally, the actual
content type is encrypted and there may be optional padding to mask the
actual size of the encrypted data.
The previous approach would lead to additional zero prefixes in the
encoding of the serial (which is a positive integer, not an arbitrary
blob).
Fixes#3667.
Also assign online leases to a peer connecting from the same endpoint
when it requests any virtual IP. This is mainly a workaround for
Windows clients that remember the virtual IPv6 address and re-request it
the next time the connection is initiated (even if it is not a
reauthentication) but don't do the same for virtual IPv4 addresses.
This can result in duplicate policies with different reqids because
these are allocated for unique sets of traffic selectors.
Fixes#3541.
This allows more fine grained control over what's updated and does not
require multiple calls of the method. Plus we'll be able to use it in
the ike-mobike task.
If we are already deleting the old/redundant CHILD_SA, we must not
migrate the child-create task as that would destroy the new CHILD_SA we
already moved to the IKE_SA.
Fixes#3644.
If no callback is specified, terminate_ike_execute() is invoked without the
listener waiting on the IKE state change.
Now, if 'force' is false, then ike_sa->delete() just queues an
IKE_DELETE task, and returns SUCCESS - indicating successful task
manager initiation.
However, terminate_ike_execute() ignored this success and set the
status to FAILED.
This is not ideal, as it will be the overall return code of
terminate_ike(), although no failure did occur. This eventually leads
vici's "terminate" to return "Command failed: terminating SA failed",
as seen in this example:
In [9]: list(session.terminate({'ike-id': 2960, 'timeout': -1}))
---------------------------------------------------------------------------
CommandException Traceback (most recent call last)
<ipython-input-9-5f95b5cea88f> in <module>()
----> 1 list(session.terminate({'ike-id': 2960, 'timeout': -1}))
vici/session.pyc in streamed_request(self, command, event_stream_type, message)
136 raise CommandException(
137 "Command failed: {errmsg}".format(
--> 138 errmsg=command_response["errmsg"]
139 )
140 )
CommandException: Command failed: terminating SA failed
If we consider both queueing the task and actually destroying the IKS_SA
a success, we can just always return SUCCESS if we don't have a
callback. There is also no need to explicitly set the status to FAILED
if a listener is waiting as that's the default anyway.
Co-authored-by: Tobias Brunner <tobias@strongswan.org>
Closesstrongswan/strongswan#185.
This ensures that e.g. ike/child-updown messages are sent that were
queued but couldn't be sent (even the job to enable to on_write() callback
requires a worker thread that's not around anymore during shutdown).
References #3602.
The message_t object used for defragmentation was only cleared after
all fragments have been received and the message was delivered. So
if we received only some fragments of a retransmitted message, the
fragments of the next message were not processed (message_t returns
INVALID_ARG if the message ID does not match causing the message to
get ignored). This rendered the IKE_SA unusable as the client
obviously never retransmitted the fragments of that previous message
after it received our response.
Note that manually adding an IPv6 address without disabling duplicate
address detection (DAD, e.g. via `nodad` when using iproute2) will cause
a roam event due to a flag change after about 1-2 seconds (TENTATIVE is
removed). If this is a problem, we might have to ignore addresses with
TENTATIVE flag when we receive a RTM_NEWADDR message until that flag is
eventually removed.
Fixes#3511.
We create the child_sa_t object when initiating the CREATE_CHILD_SA
request, however, the IP addresses/ports might have changed once we
eventually receive the response (potentially to a retransmit sent to
a different address). So update them before installing the SA and
policies.
If the local address changed too and depending on the kernel
implementation, the temporary SA created to allocate the inbound SPI
might remain as it can't be updated. This could cause issues if e.g.
the address switches back before that SA expired (the updated inbound
SA conflicts with the temporary one), or if that happens close together
and the expire (having to wait for the address update) causes the
updated SA to get deleted.
Fixes#3164.
Noel Kuntze