Re: [strongSwan] Effect of xfrm_acq_expires mismatch retransmit timeout?
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 later updated when the SA's details are known and the keys are derived. If it expired in the mean time, it's theoretically possible that the SPI was reallocated for another SA/request. But since that's unlikely (the kernel allocates them randomly) current versions of the daemon will attempt to install a new SA with the same SPI if updating fails because the temporary state has already expired. This is also the reason why the default value for xfrm_acq_expires set by the kernel-netlink plugin is based on the configured retransmission timeout. However, only for a single exchange. If e.g. IKE_AUTH requires multiple exchanges due to EAP, the SPI might still expire before the IKE_SA does. Regards, Tobias
Re: [strongSwan] Effect of xfrm_acq_expires mismatch retransmit timeout?
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
Re: [strongSwan] Effect of xfrm_acq_expires mismatch retransmit timeout?
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 > > Noel Thanks for the explanation. > > 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, >> 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 signature.asc Description: OpenPGP digital signature
[strongSwan] Effect of xfrm_acq_expires mismatch retransmit timeout?
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, -- [*] 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 signature.asc Description: OpenPGP digital signature
