i gave this some thought today. i have some experience with ATM, and hence
PVCs, and experience with IPSec VPNs.
ben's right in that there are issues about the endpoints. but, he misses
some points, i thikn.
first, the computational overhead of a VPN is pretty low, in my
experience. i've been using general purpose processors (including Intel
x86) to do VPNs with some decent traffic. they handle the loads pretty
well. if you are concerned, look at a dedicated hardware solution (though
you may not like the encryption options, which usually hover around DES).
so, sorry ben, i don't buy totally into your argument. however, i would
definitely agree that some big traffic loads would stress it.
however, some ATM equipment we had in production could be abused to a
point such that it would start shoving cells over the broadcast interface
(the BUS), and everyone could see some cells. granted we saw this on
overloaded ELANs but .. it could easily be forced. heck, simple code on
the old fore.com FTP site could be abused to do this.
if you are going to go with PVCs, add some encryption to add defense in
depth. no sense not to.
however, you may have, depending on where you plan to go with it,
difficulties in getting a decent, flexible end-to-end path set up with the
PVCs. using a generic network layer solution, like IPSec, will eliminate
that.
just some of my perspective, which i hope makes sense. i respect ben's
opinions a lot, but i sort of disagree with him based on my experience.
good luck,
____________________________
jose nazario [EMAIL PROTECTED]
PGP: 89 B0 81 DA 5B FD 7E 00 99 C3 B2 CD 48 A0 07 80
PGP key ID 0xFD37F4E5 (pgp.mit.edu)
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
