Fw: Re: Block all servers?
Fred Heutte
aoxomoxoa at sunlightdata.com
Wed Oct 15 01:12:49 UTC 2003
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
More information about the NANOG
mailing list