Hi Paul, > On Mon, 17 Oct 2022, Valery Smyslov wrote: > > [leaving cache/linux implementation details to Steffen to answer] > > > Another issue that is not clear from the draft - > > how per-CPU SAs are created. Consider the situation when > > an outgoing packet is handled by a CPU > > and there is no per-CPU Sa to handle it. Then, I assume, > > the fallback SA is used. > > Yes.
OK. > > My question - in this > > case does this CPU additionally requests IKE > > to create a per-CPU SA for it? > > Yes. In linux language, it would a per-CPU ACQUIRE to userland. OK. > > If so, then > > what happens if the other side has indicated > > that no more per-CPU SAs is allowed - > > is it saved somewhere, so that future outgoing > > packets handled by CPUs with no per-CPU SA, > > don't trigger requests to create it anymore? > > I think this is implementation specific. You could install an temporary > rule into the SPD that would give the fallback SA more priority than the > per-CPU policy installed, so it wouldn't generate ACQUIRES for a while. Why for a while? And for how long? There is no indication from the peer whether inability to create more SAs is temporary or permanent, so we may end up with wasting resources when one peer will be constantly trying to install per-CPU SA with no success. > Perhaps userland could also decide to terminate another per-CPU SA that > is idle. Although I think the advised policy is stated to install at > least one per-CPU SA per CPU (and allow a few more to catch any race > conditions and rekeys). Why more SAs than the number of CPUs are needed (not counting the Fallback SA)? If you rekey per-CPU SAs proactively you will always have a per-CPU SA ready. Or what do you mean by "race conditions" and why only few more SAs help in this case? > Clearly, if for part of the connection, you are > using the fallback SA, you are running at suboptimal speed which is not > a situation you should remain in. Why? If the peer is unwilling (or unable) to install more SAs, then you will be in this suboptimal situation forever. I don't think it's a wrong situation you want to escape from ASAP, I think it's a normal situation in general. > >> We don't require a fallback SA in the draft, we just recommend to have > >> one. So in that sense, once created, all SAs live their own live. > > > > Hmm, my impression from reading the draft is that it is not so: > > > > Section 3: > > > > When negotiating CPU specific Child SAs, the first SA negotiated > > either in an IKE_AUTH exchange or CREATE_CHILD_SA is called Fallback > > SA. > > Indeed. The idea is that no matter what, you can encrypt the packets and > send them, even if at sub-optimal speeds. We don't want packets to have > to wait another RTT for the per-CPU SA to establish. That would cause a > lot of issues (slow TCP retransmits, UDP application retransmits, etc). > Once the first SA is up, you have a working IPsec tunnel and no more > packets should be dropped or wait for SA's to establish. I understand all these considerations. My proposal is to use other existing per-CPU SA in this case. So, no special Fallback SA is needed (I understand that re-steering packet to a different CPU requires locking, but in my understanding using the Fallback SA requires locking as well). > > The Fallback Child SA MUST NOT be deleted when idle, as > > it is likely to be idle if enough per-CPU Child SAs are installed. > > > > I think that these BCP14 requirements make the fallback SA very special. > > Yes it does. It ensures there is a fully working (albeit slow) IPsec > connection. And the "specialityness" of this SA worries me. I think that the same functionality can be achieved without introducing this special SA. Regards, Valery. > Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
