Before commit 6c49ddfbca ("ike: Add additional Vendor IDs for
third-party implementations") the prefix length of vendor ID
MS NT5 ISAKMPOAKLEY was hardcoded to 16. Change the prefix length
accordingly.
Fixes: 6c49ddfbca ("ike: Add additional Vendor IDs for third-party implementations")
If there are many CHILD_SAs, the time between initiating the new IKE_SA
and checking it in might be longer (depending on what else is going on
in the daemon) than the retransmission timeout and no retransmits might
be sent afterwards for this SA (it will just linger around dead).
Calling initiate() last should avoid that (we do this similarly for MBB
reauthentication).
If we are using make-before-break reauthentication, this could lead to
duplicates as the new IKE_SA wouldn't be able to delete the previous
one if it was replaced by a rekeying.
If we initiated a make-before-break reauthentication and the peer
concurrently deletes the IKE_SA (e.g. because it uses break-before-make
reauthentication), we would create a duplicate IKE_SA (the condition forces
a recreation of all existing CHILD_SAs because reestablish() is also called
to complete a break-before-make reauthentication).
The addresses observed by the client behind the NAT are exactly the same if
the NAT router gets restarted.
Fixes: 2b255f01af ("ike-mobike: Use ike_sa_t::update_hosts() to trigger events")
This now includes all key material derived for IKE_SAs in the order
defined in the RFC:
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr}
= prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr)
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
For some that are followed by unknown data (e.g. detailed version
information) we only do a prefix match.
Co-authored-by: Tobias Brunner <tobias@strongswan.org>
Closesstrongswan/strongswan#393.
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.
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.
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.
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.
A new global option enables sending this vendor ID to prevent Cisco
devices from narrowing the initiator's local traffic selector to the
requested virtual IP, so e.g. 0.0.0.0/0 can be used instead.
This has been tested with a "tunnel mode ipsec ipv4" Cisco template but
should also work for GRE encapsulation.
Closesstrongswan/strongswan#180.
If a MOBIKE task is deferred, the retransmission counter is reset to 0
when reinitiating. So if there were retransmits before, this alert would
not be triggered if a response is received now without retransmits.
We usually have a local IP already via ike_sa_t::resolve_hosts() before
build_i() is called but if that's not the case, it's more likely we have
one after we processed the first response (it might also have changed).
There is a potential chance we still don't have one if the socket API
doesn't provide us with the destination address of received messages,
but that seems not very likely nowadays.
We need the PSK/identity already when deriving the keys in process_i().
Fixes: 1665a4e050 ("ikev1: Use actual local identity as initiator or aggressive mode responder")
Retransmission jobs for old requests for which we already received a
response previously left the impression that messages were sent more
recently than was actually the case.
task_manager_t always defined INVALID_STATE as possible return value if
no retransmit was sent, this just was never actually returned.
I guess we could further differentiate between actual invalid states
(e.g. if we already received the response) and when we don't send a
retransmit for other reasons e.g. because the IKE_SA became stale.
This is useful on Android where the app might not be able to send
keep-alives if the device is asleep for a while. If the NAT mapping
has been deleted in the mean time, the NAT-D payloads allow detecting
this and connectivity can be restored by doing a MOBIKE update or
recreating the SA if the peer already deleted it because the client
wasn't reachable.
If we fail connecting to the host we got redirected to, we should restart
with the original host where we might get redirected to a different host.
We must not reset this when retrying due to INVALID_KE_PAYLOAD or COOKIE
notifies. Since we keep the initiator SPI in those cases, we use that
flag as indicator.
Since we don't store the original remote_host value, we can't restore
that. So there is a potential conflict with MIPv6.
Closesstrongswan/strongswan#171.
Due to the exponential backoff a high number of retransmits only
makes sense if retransmit_limit is set. However, even with that there
was a problem.
We first calculated the timeout for the next retransmit and only then
compared that to the configured limit. Depending on the configured
base and timeout the calculation overflowed the range of uint32_t after
a relatively low number of retransmits (with the default values after 23)
causing the timeout to first get lower (on a high level) before constantly
resulting in 0 (with the default settings after 60 retransmits).
Since that's obviously lower than any configured limit, all remaining
retransmits were then sent without any delay, causing a lot of concurrent
messages if the number of retransmits was high.
This change determines the maximum number of retransmits until an
overflow occurs based on the configuration and defaults to UINT32_MAX
if that value is exceeded. Note that since the timeout is in milliseconds
UINT32_MAX equals nearly 50 days.
The calculation in task_manager_total_retransmit_timeout() uses a double
variable and the result is in seconds so the maximum number would be higher
there (with the default settings 1205). However, we want its result to
be based on the actual IKE retransmission behavior.
Some peers apparently don't send the notify and still expect to
authenticate with EAP-only authentication. This option allows forcing
the configured use of EAP-only authentication in that scenario.
If such a task was active while reestablishing it will get queued on the
new IKE_SA. If the DH group is already set, the DH groups won't be
stripped from the proposals and a KE payload will be sent, which is invalid
during IKE_AUTH. We don't want to reset the group if the task is part of a
child-rekey task.
Volker Rümelin