> -----Original Message-----
> From: Alfred R. Collins [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 09, 2001 10:24 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: ATM PVC as security barrier
>
>
> Our network engineer proposed ATM PVC's as a means to route
> Internet traffic
> across our corporate backbone.[...]I proposed VPN's
> as more secure
> than PVCs.
That's unclear - in fact I don't think it can be correct.
Look at it this way. It's Internet traffic, right? We don't care about
encrypting it (it's not sensitive) so we forget about ESP. All we really
have left is effectively an IP in IP tunnel.
What are the attacks against IP tunnels? Endpoint attacks, mainly.
What are the attacks against ATM PVCs? Ditto, except at a lower layer.
The crypto stuff is a red herring - the critical thing, here, is how stuff
gets put into the correct PVCs / VPN tunnels. The robustness of that method
will determine how effective your plan is. It would appear, on the face of
it, that ATM PVCs should not be attackable at layer 3, whereas VPNs most
certainly are.
[...]
>I am
> proposing that a VPN
> can protect a corporate network from the insecure Internet
> traffic confined
> within the VPN. Is this a valid assumption?
I don't think so. There's no security risk in having "nasty" packets rubbing
up against your "good" packets. I think that conceptualising VPN traffic as
being "confined" is flawed. It's no more confined than normal,
(non-source)routed IP packets.
> Note: both ends of the VPN
> terminate at a firewall that we control. Comments?
I think the VPN plan is CPU expensive and not a security win. I'd go PVCs,
but also use a bunch of IP ACLs on the OutRouter (I visualise it like this:
Internet--OutFW---OutRouter--[ATM Cloud]--InRouter--InFW--EndSite
So, even if your firewall gets rolled, the attacker should only be able to
talk to the PVCs that lead to the outside of each InFW.
Good luck.
--
Ben Nagy
Network Security Specialist
Marconi Services Australia Pty Ltd
Mb: +61 414 411 520 PGP Key ID: 0x1A86E304
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
