The new issue of Network Magazine has a cover story that may
be worth a look: "SSL VPNs: Remote Access for the Masses,"
by Andrew Conry-Murray, which makes a pretty convincing
case for the use of SSL VPNs instead of IPSec. A lot of this
is still-emerging stuff and the author, to his credit, doesn't pull
any punches saying so. But it does make the point that, although
IPSec has many admirable design ideas, deployment is sticky.
http://www.networkmagazine.com/shared/article/showArticle.jhtml?articleId15201419&classroom
In a similar vein is Lisa Phifer's "VPNs: Tunnel Visions, How do
SSL VPNs match up with their older IPSec cousins?" in the
August issue of Information Security:
http://infosecuritymag.techtarget.com/ss/0,295796,sid6_iss21_art83,00.html
Naturally, given the audience, she focuses much more on the
security specifics. Of particular interest:
IPSec prevents packet modification to thwart man-in-the-middle
attacks. However, this strong security feature also generates
operational problems. NAT frequently breaks IPSec because it
modifies packets by substituting public IP addresses for
private ones. Many IPSec products implement NAT traversal
extensions, but support for this feature isn't universal, and
interoperability is still an issue.
SSL is almost as tough against man-in-the-middle attacks,
without IPSec's NAT conflict. SSL rides on TCP, so it's
insulated from IP and port modifications, and thus passes
easily through NAT. SSL carries sequence numbers inside
encrypted packets to prevent packet injection, and TLS uses
message authentication to detect payload changes.
And Phifer notes later that one of the critical issues with SSL
VPNs is whether you want to "Webify" everything. For all
of us (I hope), the net is much more than just port 80.
fred
IPSec prevents packet modification to thwart man-in-the-middle
attacks. However, this strong security feature also generates
operational problems. NAT frequently breaks IPSec because it
modifies packets by substituting public IP addresses for
private ones. Many IPSec products implement NAT traversal
extensions, but support for this feature isn't universal, and
interoperability is still an issue.
IMHO this is a bit misleading as it implies you need some kind of
special gateway with "NAT traversal extensions" to get IPSec to work.
This is not exactly true as only AH checks the IP header. If you stick
with just ESP you can re-write IPs without failing authentication.
True this only works for one to one NAT. Many to one NAT will still
break IPSec, even if ESP is used alone. This is a functionality issue
however (IPSec using a fixed source port of 500), rather than a
"preventing packet modification to thwart man-in-the-middle attacks"
thing.
And Phifer notes later that one of the critical issues with SSL
VPNs is whether you want to "Webify" everything. For all
of us (I hope), the net is much more than just port 80.
Not so sure you really have to. This is true if you are running things
like pop3s, imaps, etc. but you can also go with something like stunnel
which is pretty close to IPSec. The biggest drawback is no native
support for UDP which makes using internal DNS a bit of a bear.
Cheers,
C
Chris Brenton wrote:
[snip]
True this only works for one to one NAT. Many to one NAT will still
break IPSec, even if ESP is used alone. This is a functionality issue
however (IPSec using a fixed source port of 500), rather than a
"preventing packet modification to thwart man-in-the-middle attacks"
thing.
IPsec does not use port 500. IKE uses port 500/udp. IKE is an additional
protocol that is widely used to establish SAs and provide keying
materials for IPsec, but it is not required for a compliant IPsec
implementation. In addition, most IKE implementations do not care
whether the source port on a IKE packet is 500/udp or not.
As I explained previously, ESP alone is un-NAT able in the general
case due to the fact that it is a peer-to-peer protocol, not client-to-
server, and the SPIs in either direction are unrelated.