> Does this mean we decide to give up older SAs as soon as we establish a new > CHILD_SA as responder? This may not be what the remote peer wants (otherwise > it would have *rekeyed* the SA instead).
No. It means that two different CHILD_SAs triggered from the same trap policy use the same reqid. Assuming a trap policy to 10.0.0.0/16, and traffic to 10.0.1.1 triggers an SA. The responder, however, narrows the traffic selector to 10.0.1.0/24. Now you have traffic to 10.0.2.1, which triggers another CHILD_SA, which might get narrowed by the responder to 10.0.2.0/24. So you'll have two CHILD_SA with the same reqid (that of the trap policy). This is problematic for the kernel, which uses the reqid to map policies to SAs. > According to what I observed, the trap CHILD_SA is left unchanged, but > the policy in the kernel is updated with the new CHILD_SA reqid (I agree > that itis necessary if we want the SA to be used). > > However, the trap CHILD_SA becomes unusable because it mismatches the > policy reqid. Yes. Because we can't have two identical policies in XFRM, we use refcounting to install it only once. This doesn't work for different reqids, as only one reqid can be active for these refcounted policies. This is why we reuse the reqid of a trap policy when installing an SA triggered by it. And this is what we should do when we install an SA as responder for which we have a trap installed. Regards Martin _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
