[Users] Announce: FreeS/WAN Project Ending
From: Claudia Schmeing <claudia@coldstream.ca> Subject: [Users] Announce: FreeS/WAN Project Ending
Dear FreeS/WAN community,
After more than five years of active development, the FreeS/WAN project will be coming to an end.
Is anyone disappointed? Is anyone surprised? FreeS/WAN garroted itself by refusing to take code contributions from people inside the U.S., out of fear that the BXA would retroactively change export policy and render those contributions poisonous. FreeS/WAN made no serious attempt to integrate with the linux kernel's routing infrastructure, no doubt due in part to the first issue above. FreeS/WAN configuration was, and probably still is, not very intuitive; diagnostics were and probably are similarly poor. Corporations, the major users of VPNs, usually use dedicated vpn boxes with support from a commercial VPN provider. If any such providers base their VPN products on FreeS/WAN, it's probably heavily modified. -- That woman deserves her revenge, and... we deserve to die. -Budd, Kill Bill
On Tue, 2 Mar 2004, Justin wrote:
From: Claudia Schmeing <claudia@coldstream.ca> Subject: [Users] Announce: FreeS/WAN Project Ending
Dear FreeS/WAN community,
After more than five years of active development, the FreeS/WAN project will be coming to an end.
Is anyone disappointed?
Yes.
Is anyone surprised?
Mildly.
FreeS/WAN garroted itself by refusing to take code contributions from people inside the U.S., out of fear that the BXA would retroactively change export policy and render those contributions poisonous.
Is there anybody with enough organizational/leadership skills to take over the project, preferably located further away of the US influence than Canada is? Export policies are relevant only when enforceable.
FreeS/WAN made no serious attempt to integrate with the linux kernel's routing infrastructure, no doubt due in part to the first issue above.
That could be relieved, given developers and skilled leadership.
FreeS/WAN configuration was, and probably still is, not very intuitive; diagnostics were and probably are similarly poor.
Again, this can be relieved, given the developers.
Corporations, the major users of VPNs, usually use dedicated vpn boxes with support from a commercial VPN provider. If any such providers base their VPN products on FreeS/WAN, it's probably heavily modified.
I maintain a small conglomerate of private and corporate networks. We use FreeS/WAN quite extensively, with great success - in last 2 years we had no drop-out caused by the crypto infrastructure fault. No attempt for opportunistic crypto on the IP level, though, at least not yet. It was a good project. Hope somebody picks up the torch and keeps it burning, possibly even brighter.
Thomas Shaddack (2004-03-02 02:49Z) wrote:
Is there anybody with enough organizational/leadership skills to take over the project, preferably located further away of the US influence than Canada is? Export policies are relevant only when enforceable.
Corporations, the major users of VPNs, usually use dedicated vpn boxes with support from a commercial VPN provider. If any such providers base their VPN products on FreeS/WAN, it's probably heavily modified.
I maintain a small conglomerate of private and corporate networks. We use FreeS/WAN quite extensively, with great success - in last 2 years we had no drop-out caused by the crypto infrastructure fault. No attempt for opportunistic crypto on the IP level, though, at least not yet.
It was a good project. Hope somebody picks up the torch and keeps it burning, possibly even brighter.
1.9 was forked and is part of USAGI's IPv6 project, which was (mostly) integrated into the 2.6 kernel. I think at this point, small portions of 1.9->2.06 diff may be integrated, but the rest, and FreeS/WAN in general, is dead as a project distinct from the kernel. The USAGI version uses cryptoapi which is much more intelligent than using gmp. I haven't looked, but I think the USAGI/2.6 implementations are much better integrated with the linux routing infrastructure. DaveM and Alexey were griping about the miserable state of FreeS/WAN in that department back when ipsec in 2.6 was being discussed. In particular, OE may not be part of 2.6 yet (I haven't used 2.6 ipsec or USAGI ipsec, so I don't know), but that's the only major thing from FreeS/WAN 2.0 I can see being integrated. And sure, you use FreeS/WAN, and a company I used to work for used it too. There are employees of many other companies who post to the FreeS/WAN lists. But that's hardly representative of the majority of companies. -- That woman deserves her revenge, and... we deserve to die. -Budd, Kill Bill
Thomas Shaddack (2004-03-02 02:49Z) wrote:
It was a good project. Hope somebody picks up the torch and keeps it burning, possibly even brighter.
And for anyone unhappy with the linux 2.6 implementation, this forked just a few months ago: http://www.openswan.org/ -- That woman deserves her revenge, and... we deserve to die. -Budd, Kill Bill
<good news snipped> :)
And sure, you use FreeS/WAN, and a company I used to work for used it too. There are employees of many other companies who post to the FreeS/WAN lists. But that's hardly representative of the majority of companies.
"Majority" as in number of employees, or as in count? Do mom-and-pop shops count as companies? Do we count majority as a share of all companies, or only as a share of some-kind-of-a-VPN users?
Thomas Shaddack (2004-03-02 06:09Z) wrote:
And sure, you use FreeS/WAN, and a company I used to work for used it too. There are employees of many other companies who post to the FreeS/WAN lists. But that's hardly representative of the majority of companies.
"Majority" as in number of employees, or as in count? Do mom-and-pop shops count as companies? Do we count majority as a share of all companies, or only as a share of some-kind-of-a-VPN users?
Lots of suits use ipsec, and those suits run windows with pgpnet or some commercial ipsec roadwarrior "solution". Those seem to be the likely majority of ipsec endpoints. As for static ipsec links, where neither side is serving only one person, you may be right that the majority of companies have at least one using frees/wan. Maybe I'm underestimating the number of corporate inter-office VPNs or developer-to-employer tunnels, and maybe most of them use frees/wan. I really have no way to know. But my impression is that developer tunnels are quite rare, and that inter-office VPNs are outnumbered by roadwarriors who don't run linux. -- That woman deserves her revenge, and... we deserve to die. -Budd, Kill Bill
On Tue, Mar 02, 2004 at 03:49:47AM +0100, Thomas Shaddack wrote: > I maintain a small conglomerate of private and corporate networks. We use > FreeS/WAN quite extensively, with great success - in last 2 years we had
no drop-out caused by the crypto infrastructure fault. No attempt for > opportunistic crypto on the IP level, though, at least not yet. What sank FreeS/WAN for me (as compared to StarTLS for opportunistic email encryption) is requirement to publish DNS records and KLIPS always failing on next kernel upgrades. Opportunistic encryption suffers from fax effect; FreeS/WAN made things unnecessarilly difficult. We have KAME/Racoon support in OS X, and IPsec seem to have been present in Windows since NT, OpenBSD has support, and now we see 2.6 kernels becoming available (Knoppix, Fedora Core 2 test1 and Mandrake seem to have it). What's needed is a good OE patch for 2.6.x which is activated and shipped in mainstream Linux distros as default (fallback to plain will probably produce visible delays). Until that happens, OE in IPsec will remind largely a pipe dream, and only grow very slowly among the early adopters. > It was a good project. Hope somebody picks up the torch and keeps it > burning, possibly even brighter. Is there a protocol flaw in IPsec which prevents it from going OE as StartTLS does? -- Eugen* Leitl leitl ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net
[demime 1.01d removed an attachment of type application/pgp-signature]
participants (4)
-
Eugen Leitl -
Justin -
R. A. Hettinga -
Thomas Shaddack