aboutsummaryrefslogtreecommitdiffstats
path: root/src/libcharon/sa
Commit message (Collapse)AuthorAgeFilesLines
...
* ikev2: Add task to handle IKEV2_MESSAGE_ID_SYNC notifies as responderTobias Brunner2017-02-085-0/+341
|
* ike: Publish getter for the current message ID on IKE_SATobias Brunner2017-02-082-1/+19
|
* ike: Add getter for the current message ID to task managerTobias Brunner2017-02-083-1/+23
|
* ikev1: Factor out IV and QM managementTobias Brunner2017-02-084-261/+498
| | | | This simplifies implementing a custom keymat_v1_t.
* keymat: Allow keymat to modify signature scheme(s)Thomas Egerer2017-02-087-18/+49
| | | | Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
* 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
|
* ikev1: Minor code optimization in task managerThomas Egerer2016-12-071-11/+5
| | | | Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
* child-sa: Use single return statement in update_usebytes()Thomas Egerer2016-11-181-4/+8
| | | | Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
* task-manager: Only trigger retransmit cleared alert if there was at least ↵Tobias Brunner2016-10-052-2/+2
| | | | | | | | one retransmit The counter is already increased when sending the original message. Fixes: bd71ba0ffb03 ("task-manager: Add retransmit cleared alert")
* ikev2: Respond with NO_PROPOSAL_CHOSEN if proposal without DH group was selectedTobias Brunner2016-10-051-0/+1
| | | | Fixes #2051.
* ikev2: Only add NAT-D notifies to DPDs as initiatorTobias Brunner2016-10-041-8/+15
| | | | | | | | | | If a responder is natted it will usually be a static NAT (unless it's a mediated connection) in which case adding these notifies makes not much sense (if the initiator's NAT mapping had changed the responder wouldn't be able to reach it anyway). It's also problematic as some clients refuse to respond to DPDs if they contain such notifies. Fixes #2126.
* ikev1: Activate task to delete the IKE_SA in state IKE_REKEYINGTobias Brunner2016-10-041-0/+8
| | | | It does not have any CHILD_SAs attached at that point.
* ikev1: Delete Quick Mode SAs before the ISAKMP SATobias Brunner2016-10-041-2/+2
| | | | | After the ISAKMP_DELETE task has been executed the IKE_SA is destroyed so we wouldn't be able to send deletes for the Quick Mode SAs.
* ikev1: Send DELETE for rekeyed IKE_SAsTobias Brunner2016-10-041-9/+5
| | | | | | If we silently delete the IKE_SA the other peer might still use it even if only to send DPDs. If we don't answer to DPDs that might result in the deletion of the new IKE_SA too.
* ike: Set default IKE fragment size to 1280Tobias Brunner2016-10-041-1/+1
| | | | | | This is the minimum size an IPv6 implementation must support. This makes it the default for IPv4 too, which presumably is also generally routable (otherwise, setting this to 0 falls back to the minimum of 576 for IPv4).
* ikev2: Send derived CHILD_SA keys to the busTobias Brunner2016-10-041-26/+43
|
* ikev2: Send derived IKE_SA keys to busTobias Brunner2016-10-041-26/+30
|
* ikev1: Send derived CHILD_SA keys to the busTobias Brunner2016-10-041-14/+26
|
* ikev1: Send derived IKE_SA keys to busTobias Brunner2016-10-041-14/+11
|
* child-sa: Only install outbound FWD policies if explicitly configuredTobias Brunner2016-09-281-14/+27
| | | | | | They are only required if drop policies would otherwise prevent forwarding traffic. This reduces the number of policies and avoids conflicts e.g. with SPD hash thresholds.
* gmp: Support of SHA-3 RSA signaturesAndreas Steffen2016-09-221-2/+2
|
* ikev2: (Re-)Queue tasks used to establish an IKE_SA in reset()Tobias Brunner2016-09-061-2/+1
| | | | | | | | | Some tasks might get removed immediately once the IKE_SA_INIT response has been handled even if there were notifies that require a restart of the IKE_SA (e.g. COOKIE or INVALID_KE_PAYLOAD). Such a task is ike_vendor, which caused vendor IDs not to get sent in a retry. This change ensures all required tasks are queued after the reset, which some callers did already anyway.
* 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.
* ikev1: Ignore the last two bytes of the Cisco Unity vendor IDTobias Brunner2016-08-241-0/+3
| | | | | | | | | These seem to indicate the major and minor version of the protocol, like e.g. for the DPD vendor ID. Some implementations seem to send versions other than 1.0 so we just ignore these for now when checking for known vendor IDs. Fixes #2088.
* ike1: Flush active queue when queueing a delete of the IKE_SATobias Brunner2016-07-191-0/+3
| | | | | | | | | | | By aborting the active task we don't have to wait for potential retransmits if the other peer does not respond to the current task. Since IKEv1 has no sequential message IDs and INFORMATIONALs are no real exchanges this should not be a problem. Fixes #1537 References #429, #1410 Closes strongswan/strongswan#48
* 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.
* ikev2: Add possibility to delay initiation of a queued taskTobias Brunner2016-06-175-66/+189
| | | | | | | | | | | Such a task is not initiated unless a certain time has passed. This allows delaying certain tasks but avoids problems if we'd do this via a scheduled job (e.g. if the IKE_SA is rekeyed in the meantime). If the IKE_SA is rekeyed the delay of such tasks is reset when the tasks are adopted i.e. they get executed immediately on the new IKE_SA. This hasn't been implemented for IKEv1 yet.
* ike: Reduce RETRY_INTERVAL a bitTobias Brunner2016-06-171-2/+2
| | | | Retry exchanges between 5 and 15 seconds after a temporary failure.
* 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-175-10/+21
| | | | over local ones
* child-cfg: Add option to prefer supplied proposals over locally configured onesTobias Brunner2016-06-172-5/+5
|
* ike-cfg: Add option to prefer supplied proposals over locally configured onesTobias Brunner2016-06-173-5/+5
|
* 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-172-7/+4
|
* 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
|
* ikev2: Check for collisions after handling IKE deletionTobias Brunner2016-06-171-1/+5
|
* 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-176-43/+52
| | | | | | | | | 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-11 14:38:39 +0000