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 _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
