[strongSwan] Effect of xfrm_acq_expires mismatch retransmit timeout?

[Noel Kuntze]

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,
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200601/836fc6e1/attachment-0001.sig>