Re: [strongSwan] Effect of xfrm_acq_expires mismatch retransmit timeout?

2020-06-02 Thread Tobias Brunner
Hi Michael, > xfrm_acq_expires is the time the kernel holds an acquire event before it > drops it. The kernel currently uses the same timeout for SPIs allocated from the kernel for inbound SAs (as done before sending IKE_AUTH/CREATE_CHILD_SA requests), which creates a temporary state that is

Re: [strongSwan] Effect of xfrm_acq_expires mismatch retransmit timeout?

2020-06-01 Thread 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

Re: [strongSwan] Effect of xfrm_acq_expires mismatch retransmit timeout?

2020-06-01 Thread Michael Schwartzkopff
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

[strongSwan] Effect of xfrm_acq_expires mismatch retransmit timeout?

2020-05-29 Thread 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