The Super FreeSWAN patch has morphed into a full blown project of it's own complete with road maps, mailing lists, CVS, and an IRC channel.
It would be very nice to get Openswan v2.10 included with FC2.
-----Forwarded Message-----
From: Ken Bantoft ken@xelerance.com To: users@lists.openswan.org, Subject: [Openswan dev] ANNOUNCE: Openswan 1.0.0 Released Date: Fri, 02 Jan 2004 20:00:44 -0500
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
We are pleased to announce the 1st release of Openswan, a formal fork of the FreeS/WAN codebase, available through http://www.openswan.org
Openswan 1.0.0 is based off the last beta of Super FreeS/WAN, and as such includes features like X.509 Digital Certificate support, AES and other ciphers, NAT Traversal, Dead Peer Detection (DPD), and adds XAUTH Server support.
The Short Frequently Asked Questions (FAQ):
- Is it interoperable with FreeS/WAN & Super FreeS/WAN?
Openswan is 100% interoperable with FreeS/WAN, SuperFreeS/WAN, and dozens of other vendor implementations of the IPsec standards.
- Does it work on Linux Kernel 2.6?
The Openswan 1.x.x releases will runn on 2.0.x, 2.2.x and 2.4.x series only. Our 2.x.x tree is in active development, and support the 2.6 kernels.
- What's happening to the future of Super FreeS/WAN?
There will be no future development on Super FreeS/WAN - the lastest tree was used to start Openswan 1.0.0 from.
- Do my configs/scripts/tools need to be updated if I change to Openswan?
Configuration + management are no different that FreeS/WAN, so config files do not need to be updated to upgrade to Openswan.
- Where do I get support?
Available via IRC, Mailing lists, or commercially through Xelerance Corporation. See http://www.openswan.org/support/ for links.
- What's changed (Since the last release of Super FreeS/WAN)?
Dead Peer Detection (DPD) fixes X.509 v0.9.37 merge 64bit cleanups for the port to ia64 (Thanks to HP for hardware) CryptoAPI for kernel 2.4.23 fixes (JuanJo) XAUTH Server Support (Thanks to Astaro for sponsoring this work. See README.XAUTH for details. Disabled in default build.)
Ken Bantoft VP Business Development ken@xelerance.com Xelerance Corporation sip://toronto.xelerance.com http://www.xelerance.com
The future is here. It's just not evenly distributed yet. -- William Gibson
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE/9hQ/PiOgilmwgkgRApswAJwK+lZtgdlRUOxy6dL1AVdWL5TA9gCgqoHW R8FCGX5j4esW5ZURYEq1ah4= =Y9/S -----END PGP SIGNATURE-----
Dev mailing list Dev@lists.openswan.org http://lists.openswan.org/mailman/listinfo/dev
On Sat, 2004-01-03 at 12:03, Dax Kelson wrote:
The Super FreeSWAN patch has morphed into a full blown project of it's own complete with road maps, mailing lists, CVS, and an IRC channel.
It would be very nice to get Openswan v2.10 included with FC2.
- Does it work on Linux Kernel 2.6?
The Openswan 1.x.x releases will runn on 2.0.x, 2.2.x and 2.4.x series only. Our 2.x.x tree is in active development, and support the 2.6 kernels.
I have no idea what their timetable is for their 2.x.x tree, but I would suspect that it would need to be in a stable state before we consider adding it to FC2.
It could be stable now, I just suspect that the smart people on the kernel team will hold off on adding third party kernel code that wasn't absolutely rock solid, and the announcement seems to imply that the 2.6 branch isn't there yet.
This is especially key since FC2 has an agressive time table...
~spot --- Tom "spot" Callaway <tcallawa(a)redhat*com> LCA, RHCE Red Hat Sales Engineer || Aurora SPARC Linux Project Leader
"The author's mathematical treatment of the conception of purpose is novel and highly ingenious, but heretical and, so far as the present social order is concerned, dangerous and potentially subversive. Not to be published." -- Aldous Huxley's "Brave New World"
On Saturday 03 January 2004 01:03 pm, Dax Kelson wrote:
The Super FreeSWAN patch has morphed into a full blown project of it's own complete with road maps, mailing lists, CVS, and an IRC channel.
It would be very nice to get Openswan v2.10 included with FC2.
v2.10? They just released 1.0.0, with 2.0.0 in development. Why do we need this when the KAME stuff is working and works with 2.6? KAME being what RHEL is using, why would OpenSWAN be needed in Core (maybe in Alternatives, since it _is_ and alternative IPsec implementation). If you need DPD and NAT-T, I guess you would want this. For straight IPsec, or PPP over L2TP over IPsec w/X.509, KAME plus the RHEL 2.4 kernel or the 2.6 kernel seems to get the job done.
Just curious as to the reason why; I looked at Super FreeS/WAN before getting White Box loaded here (which has the same patches and ipsec-tools as RHEL3). The KAME config is vastly different than the SFSWAN config. So, tell me why I should completely redo everything: if it has a Can't-Live-Without feature, then, tell us.
On Sat, 2004-01-03 at 12:14, Lamar Owen wrote:
v2.10? They just released 1.0.0, with 2.0.0 in development. Why do we need this when the KAME stuff is working and works with 2.6? KAME being what RHEL is using, why would OpenSWAN be needed in Core (maybe in Alternatives, since it _is_ and alternative IPsec implementation). If you need DPD and NAT-T, I guess you would want this. For straight IPsec, or PPP over L2TP over IPsec w/X.509, KAME plus the RHEL 2.4 kernel or the 2.6 kernel seems to get the job done.
Just curious as to the reason why; I looked at Super FreeS/WAN before getting White Box loaded here (which has the same patches and ipsec-tools as RHEL3). The KAME config is vastly different than the SFSWAN config. So, tell me why I should completely redo everything: if it has a Can't-Live-Without feature, then, tell us.
Sure, I tell you yet again...(already posted to this list on Dec 8th):
As a user and an administrator of variety of production systems IKE daemons ranging from KAME/racoon, isakmpd, Solaris 8/9 IKE, FreeSWAN, and SuperFreeSWAN, I can comment that I've found all but SuperFreeSWAN sorely lacking.
Note that Openswan is the successor to Super FreeSWAN.
The critical features an IKE daemon are:
a) Ability to be configured as VPN concentrator supporting both road warriors and remote LANs all at the same time.
b) X.509 certificate support
c) Virtual-IP support for persistent inner IP address in ESP packets. This allows no-headache IPsec through non-brain dead NATing routers/firewalls without resorting to the following.
d) NAT-T (ala ESP-over-UDP) for IPsec through brain dead NATing routers/firewalls.
The other nice features are:
e) AES support f) Notify/Delete SA (for Cisco interop) g) XAUTH support (authenticate VPN users/tunnels via PAM) h) DHCP over IPSec i) Transport mode
All these features are supported by SuperFreeSWAN/Openswan and racoon and isakmpd only support b, i and maybe "e".
IPsec deployment covers two areas
1) Secure LAN-to-LAN communication 2) Secure road warrior to HQ communication
I would say IPsec deployment for "2" clearly, clearly outweighs "1".
Basically, supporting road warriors is impossible with racoon or isakmp.
Dax Kelson Guru Labs
On Sat, 3 Jan 2004, Dax Kelson wrote:
As a user and an administrator of variety of production systems IKE daemons ranging from KAME/racoon, isakmpd, Solaris 8/9 IKE, FreeSWAN, and SuperFreeSWAN, I can comment that I've found all but SuperFreeSWAN sorely lacking.
There are more dimensions to this debate than just the number of features.
c) Virtual-IP support for persistent inner IP address in ESP packets. This allows no-headache IPsec through non-brain dead NATing routers/firewalls without resorting to the following.
d) NAT-T (ala ESP-over-UDP) for IPsec through brain dead NATing routers/firewalls.
Are you aware that these are covered by multiple IPR claims?
g) XAUTH support (authenticate VPN users/tunnels via PAM)
This is dangerous, and has been rejected in the IETF for standardization. Why again should this be done then? If you want to authenticate users/tunnels via PAM, can't this be done by creating a PAM module interfacing IKE?
Also look at Bugtraq thread: http://marc.theaimsgroup.com/?l=bugtraq&m=107124772803447&w=2
h) DHCP over IPSec
That's already supported, I guess. What you're saying is maybe "DHCP-over-IKE"? I believe that has also been rejected at the IETF, but not sure.
On Sun, Jan 04, 2004 at 09:36:45AM +0200, Pekka Savola wrote:
On Sat, 3 Jan 2004, Dax Kelson wrote:
g) XAUTH support (authenticate VPN users/tunnels via PAM)
This is dangerous, and has been rejected in the IETF for standardization. Why again should this be done then? If you want to authenticate users/tunnels via PAM, can't this be done by creating a PAM module interfacing IKE?
It's really required for a lot of setups, and it's one of the key features that makes me feel that it is probably worth the trouble if OpenSWAN 2.x is ready in time.
You aren't REQUIRED to use it, but for people who aren't in a position to dictate to their network peers what protocols to use, the ability to do XAUTH is still valuable. Sure, warn people about the potential attacks, but not everyone is in a position to dictate whether or not they will use XAUTH.
And it doesn't really matter, frankly, that it was rejected as an internet standard; it's a de-facto standard right now and making it possible for people to use it is not going to hurt Fedora or Linux...
My opinion, anyway.
michaelkjohnson
"He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/
On Tue, 2004-01-06 at 12:04, Michael K. Johnson wrote:
It's really required for a lot of setups, and it's one of the key features that makes me feel that it is probably worth the trouble if OpenSWAN 2.x is ready in time.
Plus the OpenSWAN developers say that they have no problem accepting patches from Americans. This way, if needed, RH can feed patches upstream.
I heard that the "no-patches-from-americans" was one of the major stumbling block on getting FreeSWAN into RH.
Dax Kelson
On Thursday 08 January 2004 04:33 am, Dax Kelson wrote:
Plus the OpenSWAN developers say that they have no problem accepting patches from Americans. This way, if needed, RH can feed patches upstream.
This is good.
On Thu, Jan 08, 2004 at 02:33:32AM -0700, Dax Kelson wrote:
Plus the OpenSWAN developers say that they have no problem accepting patches from Americans. This way, if needed, RH can feed patches upstream.
Yes, this is key.
I heard that the "no-patches-from-americans" was one of the major stumbling block on getting FreeSWAN into RH.
Well, we need to separate kernel space from user space.
As kernel group manager, I asked for a review of the FreeSWAN kernel patches because IPSEC was highly desirable. The review came back very long and overwhelmingly negative. It was not a case of "there are a lot of things to fix", but rather "this code is really not worth fixing". This was not just an individual opinion, but rather a shared response by all reviewers.
So the fact that they wouldn't accept patches from americans on the kernel side didn't have the opportunity to be a practical problem because our experts decided it was not fixable. It would have been a blocking problem otherwise.
When we decided that IPSEC was of strategic value, we asked David Miller to do an IPSEC stack from scratch, designed for Linux and to be acceptable to all the kernel maintainers. There is no doubt that he succeeded admirably.
The user space side, however, is an entirely different affair. David was certainly not happy with the FreeSWAN kernel patches, but while he initially worked with kame/racoon for getting IPSEC going, he saw the *SWAN development work on userspace and was impressed; he contacted me to suggest that we consider switching. Having a maintained user-space that is intended for Linux and accepts patches without trying to score political points is a big plus.
michaelkjohnson
"He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/
On Saturday 03 January 2004 09:58 pm, Dax Kelson wrote:
On Sat, 2004-01-03 at 12:14, Lamar Owen wrote:
need this when the KAME stuff is working and works with 2.6? KAME being what RHEL is using, why would OpenSWAN be needed in Core (maybe in
Note that Openswan is the successor to Super FreeSWAN.
I had already gathered that.
- Secure road warrior to HQ communication
I would say IPsec deployment for "2" clearly, clearly outweighs "1".
Basically, supporting road warriors is impossible with racoon or isakmp.
I'm not necessarily interested in the Linux road warrior. I am, however, interested in smooth interoperability with Windows XP clients. So doing the DHCP over IKE is not needed, since the WinXP stuff uses PPP/L2TP to get the IP address, and PPP can use DHCP (with the ppp-dhcp plugin). Yes, I know the WinXP implementation is ugly. But when you are doing remote astronomy where the Windows software is king, you interoperate or you don't operate.
Racoon seems to be significatly easier to configure, however.