On Thu, 10 May 2001, Ben Nagy wrote:
> Not FORE (Marconi) gear I hope! ;)
yep. specifically we saw this with the ESX 2400 edge device (ethernet/ATM
bridging). don't know the firmware versions, we ditched it some time ago
in favor of Cisco gear (part of a larger migration back to fast ethernet
on the desktop). if we exceeded 1024 SVCs, i think it was, *boom*, unicast
cells over the BUS. [note -- i only NOW noticed that you're at marconi!]
i don't think i ever saw if PVCs would undergo the same effect. one would
expect they shouldn't, given the permanence of those tables in the
switches.
> This sounds like a repeat of the VLAN effect - something that's not
> designed for security being used as a security solution. Maybe we
> should be saying "use a separate channel, end of story"?
yep. VLANs are mistakenly trated as VPNs by many, i will agree with you
here.
> OK, all I'm saying is that encryption adds nothing here. It's
> untrusted traffic, so confidentiality isn't an issue. VPNs don't make
> it any more likely that traffic will stay where it should.
now here we are in total agreement. you could source route your IP (ie
IPSec) packets, but not every transit point supports that, and if you
don't own all of the equipment between here and there, you certainly dont
know who is at what stations along the path. SVCs are, by their
definitions, indeed fully switched (a complementary effect to source
routing, in the loosest of senses -- work with me, people :)).
however, unless you are worried about traffic analysis, i think that good
encryption and strong authentication (more below) is enough to keep all
but the most determined of adversaries away (ie big governments). the
expense of breaking all of that encrypted traffic is insane.
> I think that in security terms we need firewall to send stuff in the
> right direction and we need some ACL stuff somewhere to stop the
> firewall talking to anything but the outside of inner firewalls if the
> outer firewall falls over.
yes, i agree again that ACLs are smart. however, maybe you're forgetting
the AH component of IPSec. strong authentication at the packet level.
while specific cell injecting into a specific PVC is really difficult,
cells have no other authentication mechanism other than 'it was really
hard to be here unless i should have been'.
> Assuming that BOTH these mechanisms fail (firewall r00ted, ACLs
> bypassed) then the PVC solution is the only one that might restrict
> the traffic. The PVCs may ALSO fail, but at least they're a line of
> defence - the VPNs fall over with the firewall.
right again. so, if you do need that added assurance from a PVC (which, as
i noted can be cost and flexibility prohibitive for many), be sure to add
encryption for confidentiality, integrity and authentication. my biggest
worry about using a PVC path between two remote endpoints is the cost and
flexibility. that latter point is worth it alone, i think, in this day and
age of very volitile link providers -- ones you made contracts with last
month may be dead, and their agreements null and void, next month.
indeed an interesting topic.
____________________________
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.]
