[strongSwan-dev] charon.max_ikev1_exchanges

[Tobias Brunner]

Hi Joy,

> I have noticed that by default only 3 quick mode exchanges are
> tracked for ikev1 in version 5.3.5. I was curious as to why the
> default is 3?

Since strongSwan (and I guess racoon, as used on iOS/Android)
establishes SAs sequentially this works quite well, as it should cover
the occasional overlap of the third message of one QM exchange with the
first message of another plus perhaps an INFORMATIONAL exchange.

Let me describe why there is this hard limit.  To authenticate Quick
Mode messages we need state from previous messages, in particular the
nonces collected from the first and second QM messages.  And because the
IVs used to encrypt/decrypt Phase 2 messages are not transmitted but are
initially derived from the Phase 1 exchange and then taken from the
previous Phase 2 message, we need to keep that state around too for
Phase 2 exchanges.  Because the charon daemon's codebase is quite
modularized and, of course, was optimized for IKEv2 when we started to
add IKEv1 support we had to find a place to store this data and a way to
get it to where it was actually needed.  The keymat_t implementation
that creates and holds the cryptographic primitives used to
encrypt/decrypt the messages felt like a natural choice to keep track of
the IVs and the code that generates the values for the HASH payloads.
But it complicated cleaning up the allocated state because Phase 2
exchanges could fail or succeed in lots of different places all over the
daemon, where we might not even have direct access to the keymat_t
instance.  To simplify this we store the state objects in LRU caches,
which basically clean up themselves and a relatively low size reduces
the memory footprint per IKE_SA and prevents memory exhaustion attacks
caused by invalid Phase 2 messages.

> We have a setup between an ikev1 implementation and strongswan's
> ikev1 (version 5.3.2) - lifetime of phase 1 SA are 2 minutes -
> lifetime of phase 2 SAs are 1 minute

This seems extremely low.

> I saw the following sequence in strongswan's log,
> 
> QM_1 for MID=2797947468 received
> QM_2 for MID=2797947468 sent
> QM_1 for MID=281474316 received
> QM_1 for MID=3298933230 received
> QM_1 for MID=1321662356 received
> QM_2 for MID=3298933230 sent
> 
> By the time MID=2797947468 receives QM_3, his last IV has been removed
> from the IV list for the IKE_SA and is no longer being tracked. Thus it
> seems a new IV is generated and used to decrypt message 3 resulting in
> the above error.
> 
> Hopefully I have read the code and concluded correctly. Is this expected
> behavior? 

Yes, that's exactly what happens.  Also, such overlapping QM exchanges
are not handled correctly before 5.3.4 (see #1076 in our issue tracker).

> Am I correct to conclude that at some point, depending on variables
> like lifetime, number of child_sa, etc... max_ikev1_exchanges can
> easily or eventually be reached in strongswan if the other side does
> not initiate QM exchanges one at a time?

Yes, that's possible.  But since IKEv1 SAs have to be configured very
statically you know quite well how many concurrent QM exchanges there
will be at the most per IKE_SA so you could probably adjust
max_ikev1_exchanges accordingly.

Regards,
Tobias