[strongSwan] Effect of xfrm_acq_expires mismatch retransmit timeout?
ms at sys4.de
Mon Jun 1 19:57:54 CEST 2020
On 01.06.20 19:27, Noel Kuntze wrote:
> Hello Micahel,
> xfrm_acq_expires is the time the kernel holds an acquire event before it drops it.
> The kernel only sends one acquire event for a policy, not several ones. When it receives packets with a matching policy but without a corresponding IPsec SA,
> it checks if it already sent an acquire event. If an acquire event was not reacted to within $xfrm_acq_expires seconds, that acquire event is forgotten about by the kernel.
> So basically xfrm_acq_expires is the minimum time between two acquire events for a policy.
> Kind regards
Thanks for the explanation.
> Am 29.05.20 um 15:41 schrieb Michael Schwartzkopff:
>> what would be the effect if the charon.plugins.xfrm_acq_expires does not
>> fit the charon.retransmit_* options?
>> I tried to understand what the xfrm_acq_expires exactrly does, but the
>> docs in the internet are very limited. As far as I understood, it sets a
>> timer when the SPI times out. Every time, traffic is seens for a SPI,
>> the timer is reset (?)
>> If the total retransmit timeout is larger than the xfrm_acq_expired,
>> could it happen that the SPI timed out before charon times out and the
>> encrypted communication breaks?
>> Or is there any good timing diagram for encrytped traffic though the kernel?
>> Mit freundlichen Grüßen,
Mit freundlichen Grüßen,
[*] sys4 AG
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 228 bytes
Desc: OpenPGP digital signature
More information about the Users