| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Courtesy of C.J. Adams-Collier, ZeroLag Communications, Inc.
|
|
|
|
| |
Courtesy of C.J. Adams-Collier, ZeroLag Communications, Inc.
|
|
|
|
| |
Courtesy of C.J. Adams-Collier, ZeroLag Communications, Inc.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch exports the task manager's flush to allow flushing of all
queues with one function call from ike_sa->destroy. It allows the
access of intact children during task destructoin (see git-commit
e44ebdcf) and allows the access of the task manager in
child_state_change hook.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
|
| |
|
|
|
|
| |
Fixes #437.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is especially useful on Android where we are able to send messages
even if we don't know the correct local address (this is possible
because we don't set source addresses in outbound messages). This way
we may learn the correct local address if it e.g. changed right before
reestablishing an SA.
Updating the local address later is tricky without MOBIKE as the
responder might not update the associated IPsec SAs properly.
|
|
|
|
|
|
| |
closeaction=restart|hold
This regression was introduced with c949a4d5.
|
|
|
|
|
|
|
| |
handling IKE_SA_INIT
We want to avoid this allocation if the initial message is invalid (e.g.
if the message ID is != 0).
|
|
|
|
| |
Partially based on an old patch by Adrian-Ken Rueegsegger.
|
| |
|
|
|
|
|
| |
Not directly returning a linked list allows us to change the internals of
the CHILD_SA transparently.
|
|
|
|
| |
Eliminates another three lists, 0.5KB per IKE_SA.
|
| |
|
| |
|
|
|
|
|
| |
If the responder not correctly send the correct protocol or SPI in the delete
response, we should remove the CHILD_SA regardless.
|
| |
|
|
|
|
| |
Depending on the failure, the protocol might not yet be set on the CHILD_SA.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new flag gives the kernel-interface a hint how it should priorize the
use of newly installed SAs during rekeying.
Consider the following rekey procedure in IKEv2:
Initiator --- Responder
I1 -------CREATE-------> R1
I2 <------CREATE--------
-------DELETE-------> R2
I3 <------DELETE--------
SAs are always handled as pairs, the following happens at the SA level:
* Initiator starts the exchange at I1
* Responder installs new SA pair at R1
* Initiator installs new SA pair at I2
* Responder removes old SA pair at R2
* Initiator removes old SA pair at I3
This makes sure SAs get installed/removed overlapping during rekeying. However,
to avoid any packet loss, it is crucial that the new outbound SA gets
activated at the correct position:
* as exchange initiator, in I2
* as exchange responder, in R2
This should guarantee that we don't use the new outbound SA before the peer
could install its corresponding inbound SA.
The new parameter allows the kernel backend to install the new SA with
appropriate priorities, i.e. it should:
* as exchange inititator, have the new outbound SA installed with higher
priority than the old SA
* as exchange responder, have the new outbound SA installed with lower
priority than the old SA
While we could split up the SA installation at the responder, this approach
has another advantage: it allows the kernel backend to switch SAs based on
other criteria, for example when receiving traffic on the new inbound SA.
|
| |
|
| |
|
|
|
|
|
|
| |
RFC 5996 compatible implementations MAY send an INFORMATIONAL message
with an AUTHENTICATION_FAILED if the initiator failed to authenticate us.
Handle such a message like a DELETE for an IKE_SA.
|
|
|
|
|
|
|
| |
According to RFC 5996, we MAY send an INFORMATIONAL message having an
AUTHENTICATION_FAILED. We don't do any retransmits, though, but just close
the IKE_SA after one message has been sent, avoiding the danger that an
unauthenticated IKE_SA stays alive.
|
|
|
|
|
|
| |
While this was problematic in earlier releases, it seems that it works just
fine the way we handle compression now. So there is no need to disable it over
NATed connections or when using forceencaps.
|
|
|
|
|
|
|
| |
The previous code did not properly check for the situation when the
DELETE for a redundant CHILD_SA created by a responder during a
CHILD_SA rekey collision arrives before the responder's answer to the
initiator's winning CREATE_CHILD_SA request.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
packets
|
| |
|
|\
| |
| |
| |
| |
| | |
Fixes the use of EAP methods in the non-first authentication round if the
initiator demands mutual EAP. Also mutual EAP can now be enforced when the
initiator sets rightauth=eap, not only with rightauth=any.
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | | |
Fixes retransmit of the last Main Mode or IKE_AUTH message, and correctly
queues Main Mode messages when processing of the last message is still in
progress.
|
| |/
| |
| |
| |
| |
| |
| | |
When the last request message of the initial tunnel setup is retransmitted,
we must retransmit the response instead of ignoring the request.
Fixes #295.
|
|\ \
| |/
|/|
| |
| | |
Introduces kernel backend features, sends ESP_TFC_PADDING_NOT_SUPPORTED if
kernel does not support it.
|
| | |
|
|/ |
|
|
|
|
|
|
|
| |
Setting the responder SPI to 0 can only be done while generating the
response, otherwise we'd fail to check in the IKE_SA again in case the
hash table is enabled. That's because we use the responder SPI as hash
value since 5.0.0.
|
| |
|