Hi Martin, On 05/23/2013 09:46 AM, Martin Willi wrote: >> 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. If the responder narrows the traffic selector, then should it not spawn a new security policy in the kernel, with the narrowed selector 10.0.1.0/24 and bind the new CHILD_SA to this new SP? As far as I understand, the current processing creates the CHILD_SA with a new reqid, and updates the reqid of the existing policy (to 10.0.0.0/16) accordingly, so the SA may be used for any traffic in the 10.0.0.0/16 subnet. And it also invalidates possibly formerly negotiated SAs for this policy.
And I also wonder in which condition charon may decide to narrow the selector as you describe. > 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
