Herbert Xu wrote: > On Thu, Jan 17, 2008 at 03:31:14PM +0200, Timo Teräs wrote: >> I guess the idea was that application should know about the SAs it >> created. Though a SA dump needs to be done if you want to check >> for existing entries (created by other processes, or if you are >> recovering from a crash). > > That's what SADB_GET is for. In any case KMs cannot coexist so this > is pointless. After a crash you should simply flush all states and > policies.
I thought KMs could coexist. Actually, in strongSwan you have two daemons: charon and pluto. Both can run at the same time. The other is for IKEv1 and the other one for IKEv2. It uses netlink, though. Looking the way pfkey works, it looks like being designed to work with multiple KMs (e.g. acquires are sent to all registered sockets). >> SPD dumping is still a must if you want to work nicely with kernel. > > No it isn't. Look at how Openswan does it. No dumping anywhere at all. Then you have to have all policy/static association configuration in the application configuration. ipsec-tools wanted separate that. As this is more robust if someone decided to run multiple KMs. My point (as an ipsec-tools developer) is that the patch would fix a lot of problems until ipsec-tools is netlink enabled. It would handle perfectly the dumping even as non-atomic. And that ipsec-tools is the KM you get by default in almost all distributions. But apparently you are too worried that all the so many other KMs still using pfkey (is there others? I think most others use netlink already) in Linux might break because the rely on an unspecified feature of pfkey. I'm also tired of arguing since this is going nowhere. I'll run my patched kernel and try to get ipsec-tools fixed to use netlink... eventually. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
