aboutsummaryrefslogtreecommitdiffstats
path: root/src/libcharon/sa/ikev2/tasks
Commit message (Collapse)AuthorAgeFilesLines
* auth-cfg: Store signature schemes as signature_params_t objectsTobias Brunner2017-11-081-2/+3
| | | | | Due to circular references the hasher_from_signature_scheme() helper does not take a signature_params_t object.
* ike: Do not send initial contact only for UNIQUE_NEVERThomas Egerer2017-11-021-1/+0
| | | | Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
* libcharon: Added Cisco FlexVPN Supported VIDAndreas Steffen2017-10-271-0/+2
|
* child-create: Don't consider a DH group mismatch as failure as responderTobias Brunner2017-09-181-1/+0
| | | | | | | This causes problems e.g. on Android where we handle the alert (and reestablish the IKE_SA) even though it usually is no problem if the peer retries with the requested group. We don't consider it as a failure on the initiator either.
* child-delete: Only let SAs expire naturally if they not already didTobias Brunner2017-09-151-1/+1
|
* ike: Reset local SPI if retrying to connect in state IKE_CONNECTINGTobias Brunner2017-09-041-2/+2
| | | | | | | | | | | | | | In case we send retransmits for an IKE_SA_INIT where we propose a DH group the responder will reject we might later receive delayed responses that either contain INVALID_KE_PAYLOAD notifies with the group we already use or, if we retransmitted an IKE_SA_INIT with the requested group but then had to restart again, a KE payload with a group different from the one we proposed. So far we didn't change the initiator SPI when restarting the connection, i.e. these delayed responses were processed and might have caused fatal errors due to a failed DH negotiation or because of the internal retry counter in the ike-init task. Changing the initiator SPI avoids that as we won't process the delayed responses anymore that caused this confusion.
* ike-init: Fail if DH group in KE payload does not match proposed groupTobias Brunner2017-09-041-1/+5
|
* child-create: Don't log CHILD_SA initiation until we know the unique IDTobias Brunner2017-08-071-11/+13
|
* child-rekey: Add CHILD_SA name and unique ID to collision log messagesTobias Brunner2017-08-071-8/+13
|
* child-rekey: Don't install outbound SA in case of lost collisionsTobias Brunner2017-08-073-21/+66
| | | | | | | This splits the SA installation also on the initiator, so we can avoid installing the outbound SA if we lost a rekey collision, which might have caused traffic loss depending on the timing of the DELETEs that are sent in both directions.
* child-sa: Install outbound SA immediately if kernel supports SPIs on policiesTobias Brunner2017-08-071-3/+3
|
* ike: Trigger CHILD_INSTALLED state change after corresponding log messageTobias Brunner2017-07-271-6/+6
| | | | | | | | This way we get the log message in stroke and swanctl as last message when establishing a connection. It's already like this for the IKE_SA where IKE_ESTABLISHED is set after the corresponding log message. Fixes #2364.
* linked-list: Change return value of find_first() and signature of its callbackTobias Brunner2017-05-261-6/+7
| | | | This avoids the unportable five pointer hack.
* child-delete: Delay the removal of the inbound SA of rekeyed CHILD_SAsTobias Brunner2017-05-232-6/+50
| | | | | | | | After deleting a rekeyed CHILD_SA we uninstall the outbound SA but don't destroy the CHILD_SA (and the inbound SA) immediately. We delay it a few seconds or until the SA expires to allow delayed packets to get processed. The CHILD_SA remains in state CHILD_DELETING until it finally gets destroyed.
* child-sa: Remove state to track installation of half the SA againTobias Brunner2017-05-233-11/+2
|
* child-delete: Track flags per individual CHILD_SATobias Brunner2017-05-231-47/+78
|
* ikev2: Delay installation of outbound SAs during rekeying on the responderTobias Brunner2017-05-233-10/+92
| | | | | | | | The responder has all the information needed to install both SAs before the initiator does. So if the responder immediately installs the outbound SA it might send packets using the new SA which the initiator is not yet able to process. This can be avoided by delaying the installation of the outbound SA until the replaced SA is deleted.
* child-sa: Change API used to set/install policiesTobias Brunner2017-05-231-12/+14
| | | | This way we only have to pass the traffic selectors once.
* child-create: Trigger NARROW_RESPONDER_POST hook before installing SAsTobias Brunner2017-05-231-25/+21
| | | | | This makes sure we use the same set of traffic selectors when installing the SAs and installing the policies.
* child-cfg: Use flags for boolean optionsTobias Brunner2017-05-231-3/+3
| | | | Makes it potentially easier to add new flags.
* ikev2: Ignore IKEV2_MESSAGE_ID_SYNC notifies if extension is disabledTobias Brunner2017-02-081-0/+7
| | | | | | | | | | If this is the first message by the peer, i.e. we expect MID 0, the message is not pre-processed in the task manager so we ignore it in the task. We also make sure to ignore such messages if the extension is disabled and the peer already sent us one INFORMATIONAL, e.g. a DPD (we'd otherwise consider the message with MID 0 as a retransmit).
* ikev2: Don't increase expected MID after handling MID sync messageTobias Brunner2017-02-081-3/+1
| | | | | | | | If the responder never sent a message the expected MID is 0. While the sent MID (M1) SHOULD be increased beyond the known value, it's not necessarily the case. Since M2 - 1 would then equal UINT_MAX setting that MID would get ignored and while we'd return 0 in the notify we'd actually expect 1 afterwards.
* ikev2: Negotiate support for IKE message ID synchronisation during IKE_AUTHTobias Brunner2017-02-081-0/+7
|
* ikev2: Add task to handle IKEV2_MESSAGE_ID_SYNC notifies as responderTobias Brunner2017-02-082-0/+333
|
* ike-auth: Don't send INITIAL_CONTACT if remote ID contains wildcardsTobias Brunner2017-02-061-1/+2
| | | | | | Such an identity won't equal an actual peer's identity resulting in sending an INITIAL_CONTACT notify even if there might be an existing IKE_SA.
* Implemented EdDSA for IKEv2 using a pro forma Identity hash functionAndreas Steffen2016-12-141-0/+32
|
* ikev2: Respond with NO_PROPOSAL_CHOSEN if proposal without DH group was selectedTobias Brunner2016-10-051-0/+1
| | | | Fixes #2051.
* ikev2: Send derived CHILD_SA keys to the busTobias Brunner2016-10-041-26/+43
|
* ikev2: Store proposal on IKE_SA before creating DH objectTobias Brunner2016-09-061-2/+5
| | | | This might be useful for custom implementations of keymat_t.
* child-rekey: Only rekey installed CHILD_SAsTobias Brunner2016-06-171-7/+14
| | | | | | | | | | | | Depending on the lifetimes a CHILD_SA we rekeyed as responder might expire shortly afterwards. We don't want to rekey it again. When retrying due to an INVALID_KE_PAYLOAD notify the expected state is CHILD_REKEYING if it is anything else (e.g. due to a collision) we ignore it. We also abort the exchange properly if we don't find the CHILD_SA, no need for an empty INFORMATIONAL exchange anymore.
* child-rekey: Ignore failed colliding CHILD_SA rekeyingsTobias Brunner2016-06-171-1/+10
| | | | | | | If a passive rekeying fails due to an INVALID_KE_PAYLOAD we don't want to consider this task later when resolving collisions. This previously might have caused the wrong SA to get deleted/installed based on the nonces in the unsuccessful exchange.
* child-create: Retry creating the CHILD_SA if TEMPORARY_FAILURE is receivedTobias Brunner2016-06-171-4/+33
| | | | We queue a delayed task that is initiated after a while.
* ike-rekey: Return TEMPORARY_FAILURE when concurrently creating a CHILD_SATobias Brunner2016-06-171-14/+35
|
* ike: Add configuration option to switch to preferring supplied proposals ↵Tobias Brunner2016-06-172-4/+8
| | | | over local ones
* child-cfg: Add option to prefer supplied proposals over locally configured onesTobias Brunner2016-06-171-1/+1
|
* ike-cfg: Add option to prefer supplied proposals over locally configured onesTobias Brunner2016-06-171-1/+1
|
* ike-rekey: Make sure to ignore task when detecting collisions if ike-init ↵Tobias Brunner2016-06-171-1/+2
| | | | | | | subtask failed For instance, if INVALID_KE_PAYLOAD is returned we don't want this task to affect any active rekeying (no new SA has been established so far).
* ike-rekey: Handle undetected collisions also if delete is delayedTobias Brunner2016-06-171-16/+26
| | | | | | | | | | | If the peer does not detect the rekey collision and deletes the old IKE_SA and then receives the colliding rekey request it will respond with TEMPORARY_FAILURE. That notify may arrive before the DELETE does, in which case we may just conclude the rekeying initiated by the peer. Also, since the IKE_SA is destroyed in any case when we receive a delete there is no point in storing the delete task in collide() as process_i() in the ike-rekey task will never be called.
* ike-rekey: There is no passive reauth task, so it will never collide with oneTobias Brunner2016-06-171-3/+2
|
* ike-rekey: Ignore colliding rekey tasks that did not create an IKE_SATobias Brunner2016-06-171-56/+64
| | | | | This simplifies collision handling and we don't need to know about these tasks when concluding the rekeying we initiated.
* ike-rekey: Properly handle situation if the peer did not notice the rekey ↵Tobias Brunner2016-06-171-0/+11
| | | | | | | | | | collision We conclude the rekeying before deleting the IKE_SA. Waiting for the potential TEMPORARY_FAILURE notify is no good because if that response does not reach us the peer will not retransmit it upon our retransmits of the rekey request if it already deleted the IKE_SA after receiving our response to the delete.
* ike-delete: Handle deletes while rekeying differently if there was a collisionTobias Brunner2016-06-171-2/+40
| | | | | We treat these as if we concluded the rekeying, the active ike-rekey task will handle the collision afterwards.
* ike-rekey: Add method to check if there was a rekey collisionTobias Brunner2016-06-172-1/+17
|
* child-delete: Reply as usual when concurrently rekeying the IKE_SATobias Brunner2016-06-171-5/+1
| | | | | As per RFC 7296, 2.25.2 (what we did before was the behavior described in RFC 4718).
* child-create: Respond with TEMPORARY_FAILURE while rekeying/deleting IKE_SATobias Brunner2016-06-171-2/+2
|
* ike-rekey: Respond with TEMPORARY_FAILURE if CHILD_SAs are currently ↵Tobias Brunner2016-06-171-1/+8
| | | | rekeyed/deleted/established
* ike-rekey: Handle TEMPORARY_FAILURE notifyTobias Brunner2016-06-171-8/+22
|
* ike-rekey: Respond with TEMPORARY_FAILURE if we are deleting the SATobias Brunner2016-06-171-0/+5
|
* ike-delete: No need to wait for a response in case of concurrent deletesTobias Brunner2016-06-171-14/+0
| | | | | RFC 7296 explicitly says we SHOULD reply as usual and forget about our own close request.
* ikev2: Add a new state to track rekeyed IKE_SAsTobias Brunner2016-06-172-31/+16
| | | | | | | | | This makes handling such IKE_SAs more specifically compared to keeping them in state IKE_CONNECTING or IKE_ESTABLISHED (which we did when we lost a collision - even triggering the ike_updown event), or using IKE_REKEYING for them, which would also be ambiguous. For instance, we can now reject anything but DELETES for such SAs.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-02 19:30:52 +0000