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, >
signature.asc
Description: OpenPGP digital signature
