Hi, Martin Thank you for your generous reply. I have a question about the field 'spi' in the 'tmpl' structure. When an IPsec policy triggers the establishment of an SA, charon always tries to negotiate a CHILD_SA, and then sends the new SA and also the updated policy (adding the 'tmpl' structure) to the kernel through netlink or PF_key socket. But, at this time, seems the charon doesn't assign the field 'tmpl->id.spi' (with the proper value from structure ipsec_sa_t), jsut leave the field 'spi' with the value 0? If strongswan doesn't support PFP, there is 1:1 mapping between the policy and SA bundle, right ? So, giving the 'tmpl->id.spi' with the proper value will make sense when updating the policy after a new SA has been established, right ? Any other considerations about transferring the field 'tmpl->id.spi' between charon and kernel?
Best Regards, Allen 2013/1/10 Martin Willi <[email protected]> > > > From the strongswan view, how to treat this PFP feature? Is there any > > plan to implement this PFP feature for strongswan? > > We currently have no plans to implement such a functionality. > > > Does also Linux Kernel need to be updated to support PFP > > feature? > > Probably not. XFRM sends the details of the packet triggering the SA to > the keying daemon. Based on that, charon could negotiate SAs specific to > this traffic selector. > > Regards > Martin > >
_______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
