Linux.com

Good grief man! Are you the author of the IPSec spec? Why are you taking it
so personally?

Well, you're right I should have had more polished word (beside this, I'm far
to be a native english speaker, so I can't do much subtlety on the wording).

Anyway, this article sound like a troll, so no wonder where irritation come
from. How necessary is it to spread such inacurate bullshit on IPsec and most
other OpenVPN alternatives all the long to show the OpenVPN strong points ?

I also like OpenVPN, and prefer it over IPsec for certain usages, but really,
such a biased article only gave the need to take the oposite side to
restore balance. In particular when it comes to be wrong.

I've (as network security admin) suffered from many networks breakages
(and even intrusion, at the vtun ol'time) because of PHB coming arrogantly
with the latest ultra-cool-vpn-thingy seen on a random website for executives
to install for yesterday on an already designed network..., so here about
more personal motivations.

He offered a good paper that may have a flaw or two but, it is still far
better than almost anything else on this site and is much more coherent than
your post.

But I don't pretend to write a new article telling the world what security
of networks is<nobr> <wbr></nobr>... sorry, a comment doesn't claim the same authority than an
article

Furthermore, those OSes that include IP V4 IPSec implementations are so
convoluted and difficult to configure and manage that almost everyone uses a
separately installed third party client for their VPN implementations.

Not quite. All the OS I cited have IPsec for IPv4. And (except, yes, Windows)
native stack is very widely used, I think, when IPsec is needed.
For the windows exception: Microsoft try to encourage a mixed l2tp with
IPsec tranport usage (rather than IPsec tunnel). So in order to make it
integration easy with pure IPsec solutions, a third party client may be
better. Anyway with an l2tp capable "serveur", the builtin stack is very
efficient, and (as far as we talk of easy deployment) integrates well
with tools for software configuration management.

Or are you going to suggest that the typical salesdroid roadwarrior can
configure Microsoft's IPSec client themsleves, or even Cisco's for that
matter. What's IPSec? What's IKE? What's ISAKMP? What's an IP address? What's
my password?

That's really not the point of the discussion. The article isn't
about those people (and when would them try to implement or setup a
corporate security policy ? that not theire job). They won't manage
certificates either, nor configure OpenVPN.
A VPN solution mostly implies gateways, configured by administrators,
If workstations are concerned, entreprises needs deploying facilities:
integration with the tools for centralized deployment, administration
and management.

Most people will require VPN hardware throughput to be FAR below 45Mbps

Seems like you weren't talking about (in my experience, pretty common) case
of remote access to file servers, did you ?

But IPSec is not without issues either

I didn't said the contrary, in any way. I said that claiming the superiority
of ovpn over IPsec for security as he does is just not serious. He does
this for a very large part of the article, so it worst be contested.

but is still easier to implement than IPSec and in that respect it is dead
on, regardless of your opinion.

Well, it seems that I didn't made it clear enough on the comment: this
assertion as no sense ! No one can say, comparings those, that one is simplier
than the other. As a proof, let me claim, just to take the opposite side,
that IPsec is easier:
1- because there are differents implementations of IPsec tools, with different
"ease of use" levels.
(Free|Open|Strong)Swan are (at my knowledge) among the ugliest. For instance
to have a simple yet working IPsec setup on two OpenBSD 3.8 gateways, I only
need to edit two config file lines on each (using the 'ipsecctl' tool).
2- because the wide possibilities of differents IPsec implementations allows
things that would need nasty twisted shell scripting with ovpn on unix, and
nearly impossible with ovpn on win : auth and certs fetch trough ldap, auth
tokens on smartcard and other pkcs#11 devices, usage of enterprise PKI
solutions (involving OCSP, CRL, precise usage of certs fields), pre-auth
trough biometric devices, keys in reverse dns (and "opportunistic encryption")
etc...
3- because in many place, integrating with existing setups (that implements,
surprise, standards protocols), like routers, is only possible with this.

#