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

Noel

Am 29.05.20 um 15:41 schrieb Michael Schwartzkopff:
> Hi,
> 
> 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,
> 

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to