Posted by: Anonymous Coward
on September 28, 2005 11:50 PM
One, IPsec has too many possible configurations
Yes, everything is not like you're personal winux/i386 based network<nobr> <wbr></nobr>... For professionals, networks can get complex, you know, and need specifics setups... Like many things not doable with OpenVPN
Also, not everybody needs simultaneously authentification and encryption, or PFS, or non-repudiation<nobr> <wbr></nobr>... and want to spend money for ressources for something they don't need. I mean, on large networks
Two, the nature of IPsec requires it to be tightly coupled with the OS kernel. This is bad for any application,
Ah ? Then you're looking for an userland TCP/IP stack, I guess<nobr> <wbr></nobr>...
Didn't you understand why IPsec was in kernel ? it work at IP level, IPsec is part of any conform implementation of the IP stack for next generation, IPv6 (the standard was later on backported to IPv4). It is on kernels because IT IS TCP/IP.
And it need to be fast enough for high volume traffic of today networks (having those crypto operation on kernel avoid many context switches and memory copys). OpenVPN is for SOHO, small network with small traffic, with very simple configurations needs.
IPsec VPNs are implemented in kernel space, SSL VPNs do not have this requirement.
I guess you push packets on the wire from userland ? And you get get random source from a random deamon rather than<nobr> <wbr></nobr>/dev/*random ? And you don't use kernel crypto accelleration as provided by OpenSSL ? If you do one of this, then you basicaly use the kernel for the same things IPsec does, except that you get more exchanges with the userland.
You find more secure to have youre kernel get the data, push it to userland, then userland push it back to the kernel, then the kernel does operations (giving randomness, crypto, pushing packets to firewall or network interface...) ?
Appart from this, don't you understand that the IPsec part residing on the kernel shoud be as secure as the TCP/IP stack you rely on with OpenVPN ? Other (non IP) parts of IPsec protocols (like IKE/ISAKMP) runs on userland, like does OpenVPN.
After spending several days installing and configuring OpenS/WAN
Yes, so you tried the worst and weakest implementation of IKE/IPsec suite ever, you failed, then "IPsec is crap" ? Then for all you're paper, IPsec is the damn har thing to configure ? Wouldn't it be more honest to test other implementations before writing all this ?
IPsec VPNs require administrators to install a client component on machines that need to participate in this extended network. [...] OpenVPN uses the same architecture. No differences, no tricks. OpenVPN requires client installation just like IPsec
Plain lies ! IPsec stack is included out-of-the-box on all modern OS.
IPsec for so long, because it provides the gold standard for device-to-device communication over untrusted networks. OpenVPN matches this standard and takes it a step further.
Well, you entirly miss the point here: IPsec is an IETF standard, while OpenVPN is not a standard at all. Huge difference, you see ? You can't make OpenVPN talk to you're infratstructure Cisco (or other) router, simply because it's not standard (and not fast enough of course). Actually any IPv6 compliant network stack implementation must support IPsec (it means: windows, Linux kernel (2.6), *BSD, Mac OS X, Solaris, HP-UX, Cisco, Juniper, Checkpoint VPN*, AIX,<nobr> <wbr></nobr>...).
The very reason we want to move away from IPsec is to avoid its complexity.
Very guessable from youre paper content. But then, you shouldn't have tried to rant against IPsec like if you where a security expert<nobr> <wbr></nobr>...
we saw earlier this year in broken IPsec implementations that would
Again, you didn't you're homework, and you confuse what is from the implementations and what come from the standards. The weakness was on the protocol (the standard), not on "some broken IPsec implementations". One design error is very infortunate. But IPsec as beneficied from a large audit, reflexion, analysis from the expert community, as a standard process of the RFCs writing, and still after this (because it's an industry standard). OpenVPN can't have beneficied for such an in-depth audit (but design bugs -with worst consequences, btw- have already emerged, see below).
easy-to-install clients for Windows, Solaris, Linux, BSD, and MacOSX. (Let's see your Cisco or Checkpoint VPN do that!)
Yeah, IPsec is included in standard on all those OS (including Cisco IOS and Checkpoint one). So there's nothing to install. BTW, by using a standard, all those OS / devices can interoperate to make a VPN seemlessly.
With every compromise of an IPsec process, you get a free root shell.
Oh yes ? then you should try "privsep"'ed IKE daemons (like OpenBSD's isakmpd). There the IKE deamon is chrooted and unprivilegied, as OpenVPN. As for OpenVPN, that only a question of implementation (and in no way related to IPsec standards).
It's the perfect symptom of youre paper: you doesn't see the difference beetwheen the IPsec standard protocols suite, and the particular (and dirty) implementation you tried. Can you get a "root shell" from a bug on the TCP/IP implementation of you're kernel ? not so probable, and for the same reason, you won't get a "root shell" for the kernel part of an IPsec implem.
And talking about implementation, OpenVPN doesn't have a good security record. See, after a quick search for only the last two monthes OpenVPN vulns :
OpenVPN MAC Address Spoofing Denial Of Service Vulnerability : <a href="http://www.securityfocus.com/bid/14608" title="securityfocus.com">http://www.securityfocus.com/bid/14608</a securityfocus.com>
OpenVPN Failed Authentication Denial Of Service Vulnerability : <a href="http://www.securityfocus.com/bid/14605" title="securityfocus.com">http://www.securityfocus.com/bid/14605</a securityfocus.com>
OpenVPN Same Client Certificate Denial Of Service Vulnerability : <a href="http://www.securityfocus.com/bid/14610" title="securityfocus.com">http://www.securityfocus.com/bid/14610</a securityfocus.com>
OpenVPN Packet Decryption Failure Denial Of Service Vulnerability : <a href="http://www.securityfocus.com/bid/14607" title="securityfocus.com">http://www.securityfocus.com/bid/14607</a securityfocus.com>
You also miss an important point: beside you're (looking really SOHO and not so professional, given you're hard time to configure it and to understand IPsec basics) network routers and gateways are usually embedded devices, and route a huge amount of traffic. There, no userland solution can be of use.
OpenVPN is slow, kernel IPsec implementations are fast. That is.
Oh, and by the way, IPsec implies crypto, but isn't at all an "SSL VPN" (Do you know what the "socket" in "SSL" means ? See, network crypto != SSL). Even youre title is unacurate. You're entire paper is all FUD, uninformed and unbalanced.
Learn about Linux
Download Linux
Get Linux help
Uninformed FUD
Posted by: Anonymous Coward on September 28, 2005 11:50 PMYes, everything is not like you're personal winux/i386 based network<nobr> <wbr></nobr>...
For professionals, networks can get complex, you know, and need specifics
setups... Like many things not doable with OpenVPN
Also, not everybody needs simultaneously authentification and encryption,
or PFS, or non-repudiation<nobr> <wbr></nobr>... and want to spend money for ressources for
something they don't need. I mean, on large networks
Two, the nature of IPsec requires it to be tightly coupled with the OS kernel.
This is bad for any application,
Ah ? Then you're looking for an userland TCP/IP stack, I guess<nobr> <wbr></nobr>...
Didn't you understand why IPsec was in kernel ? it work at IP level,
IPsec is part of any conform implementation of the IP stack for next generation, IPv6
(the standard was later on backported to IPv4).
It is on kernels because IT IS TCP/IP.
And it need to be fast enough for high volume traffic of today networks
(having those crypto operation on kernel avoid many context switches and
memory copys). OpenVPN is for SOHO, small network with small traffic, with
very simple configurations needs.
IPsec VPNs are implemented in kernel space, SSL VPNs do not have this
requirement.
I guess you push packets on the wire from userland ? And you get
get random source from a random deamon rather than<nobr> <wbr></nobr>/dev/*random ? And you
don't use kernel crypto accelleration as provided by OpenSSL ? If you do
one of this, then you basicaly use the kernel for the same things IPsec does,
except that you get more exchanges with the userland.
You find more secure to have youre kernel get the data, push it to userland,
then userland push it back to the kernel, then the kernel does operations
(giving randomness, crypto, pushing packets to firewall or network
interface...) ?
Appart from this, don't you understand that the IPsec part residing on the
kernel shoud be as secure as the TCP/IP stack you rely on with OpenVPN ?
Other (non IP) parts of IPsec protocols (like IKE/ISAKMP) runs on userland,
like does OpenVPN.
After spending several days installing and configuring OpenS/WAN
Yes, so you tried the worst and weakest implementation of IKE/IPsec suite
ever, you failed, then "IPsec is crap" ? Then for all you're paper, IPsec
is the damn har thing to configure ?
Wouldn't it be more honest to test other implementations before writing all this ?
IPsec VPNs require administrators to install a client component on machines
that need to participate in this extended network.
[...]
OpenVPN uses the same architecture. No differences, no tricks. OpenVPN
requires client installation just like IPsec
Plain lies ! IPsec stack is included out-of-the-box on all modern OS.
IPsec for so long, because it provides the gold standard for device-to-device
communication over untrusted networks. OpenVPN matches this standard and takes
it a step further.
Well, you entirly miss the point here: IPsec is an IETF standard, while OpenVPN is
not a standard at all. Huge difference, you see ?
You can't make OpenVPN talk to you're infratstructure Cisco (or other)
router, simply because it's not standard (and not fast enough of course).
Actually any IPv6 compliant network stack implementation must support IPsec
(it means: windows, Linux kernel (2.6), *BSD, Mac OS X, Solaris, HP-UX,
Cisco, Juniper, Checkpoint VPN*, AIX,<nobr> <wbr></nobr>...).
The very reason we want to move away from IPsec is to avoid its complexity.
Very guessable from youre paper content. But then, you shouldn't have tried
to rant against IPsec like if you where a security expert<nobr> <wbr></nobr>...
we saw earlier this year in broken IPsec implementations that would
Again, you didn't you're homework, and you confuse what is from the
implementations and what come from the standards. The weakness was on the
protocol (the standard), not on "some broken IPsec implementations".
One design error is very infortunate. But IPsec as beneficied from a large
audit, reflexion, analysis from the expert community, as a standard process of the
RFCs writing, and still after this (because it's an industry standard).
OpenVPN can't have beneficied for such an in-depth audit (but design bugs -with
worst consequences, btw- have already emerged, see below).
easy-to-install clients for Windows, Solaris, Linux, BSD, and MacOSX. (Let's
see your Cisco or Checkpoint VPN do that!)
Yeah, IPsec is included in standard on all those OS (including Cisco IOS and
Checkpoint one). So there's nothing to install. BTW, by using a standard, all
those OS / devices can interoperate to make a VPN seemlessly.
With every compromise of an IPsec process, you get a free root shell.
Oh yes ? then you should try "privsep"'ed IKE daemons (like OpenBSD's isakmpd).
There the IKE deamon is chrooted and unprivilegied, as OpenVPN.
As for OpenVPN, that only a question of implementation (and in no way related
to IPsec standards).
It's the perfect symptom of youre paper: you doesn't see the difference
beetwheen the IPsec standard protocols suite, and the particular (and dirty)
implementation you tried. Can you get a "root shell" from a bug on the TCP/IP
implementation of you're kernel ? not so probable, and for the same reason,
you won't get a "root shell" for the kernel part of an IPsec implem.
And talking about implementation, OpenVPN doesn't have a good security record.
See, after a quick search for only the last two monthes OpenVPN vulns :
OpenVPN MAC Address Spoofing Denial Of Service Vulnerability :
<a href="http://www.securityfocus.com/bid/14608" title="securityfocus.com">http://www.securityfocus.com/bid/14608</a securityfocus.com>
OpenVPN Failed Authentication Denial Of Service Vulnerability :
<a href="http://www.securityfocus.com/bid/14605" title="securityfocus.com">http://www.securityfocus.com/bid/14605</a securityfocus.com>
OpenVPN Same Client Certificate Denial Of Service Vulnerability :
<a href="http://www.securityfocus.com/bid/14610" title="securityfocus.com">http://www.securityfocus.com/bid/14610</a securityfocus.com>
OpenVPN Packet Decryption Failure Denial Of Service Vulnerability :
<a href="http://www.securityfocus.com/bid/14607" title="securityfocus.com">http://www.securityfocus.com/bid/14607</a securityfocus.com>
You also miss an important point: beside you're (looking really SOHO and not
so professional, given you're hard time to configure it and to understand
IPsec basics) network routers and gateways are usually embedded devices, and
route a huge amount of traffic. There, no userland solution can be of use.
OpenVPN is slow, kernel IPsec implementations are fast. That is.
Oh, and by the way, IPsec implies crypto, but isn't at all an "SSL VPN"
(Do you know what the "socket" in "SSL" means ? See, network crypto != SSL).
Even youre title is unacurate.
You're entire paper is all FUD, uninformed and unbalanced.
#