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