From proff Wed Aug 28 01:31:28 1996 Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id BAA10424 for best-of-security; Wed, 28 Aug 1996 01:31:27 +1000 Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by suburbia.net (8.7.4/Proff-950810) with ESMTP id XAA30342 for ; Tue, 27 Aug 1996 23:51:13 +1000 Received: from miles.greatcircle.com by relay2.UU.NET with ESMTP (peer crosschecked as: miles.greatcircle.com [198.102.244.34]) id QQbeot06773; Tue, 27 Aug 1996 09:49:27 -0400 (EDT) Received: (majordom@localhost) by miles.greatcircle.com (8.7.1-lists/Lists-960417-1) id GAA28439 for firewalls-outgoing; Tue, 27 Aug 1996 06:00:57 -0700 (PDT) Received: from mail.rc.toronto.on.ca ([207.6.29.231]) by miles.greatcircle.com (8.7.4/Miles-951221-1) with SMTP id GAA28388 for ; Tue, 27 Aug 1996 06:00:35 -0700 (PDT) Received: by mail.rc.toronto.on.ca with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BB93F5.BAFC7B40@mail.rc.toronto.on.ca>; Tue, 27 Aug 1996 08:57:09 -0400 Message-ID: From: Russ To: "'Jerry Mendes'" , "'smith@sctc.com'" Cc: "'firewalls@GreatCircle.COM'" Subject: RE: Holes In Frame Relay Date: Tue, 27 Aug 1996 08:57:02 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: proff Precedence: bulk I set up a FR cloud here a while back so let me give you a little hands-on experience using ACC routers. The PVCs that are available for connection are not defined by the user, but are created by the Telco. I can add all the DLCIs I want, but if the Telco hasn't made them active and associated with a physical connection to their cloud, their meaningless. Once the DLCIs have been established in the cloud, then all of the routers need to have the DLCIs associated with PVCs, thereby establishing routes. Some providers offer point-to-point circuits, others offer a fully meshed environment. If the customer doesn't have a fully meshed environment, then PVCs can only be established based on purchased connections (i.e. they have to tell the Telco which DLCIs are going to talk to each other). In a fully meshed environment, the purchase of a new DLCI gives the customer the ability to establish PVCs between it and all other DLCIs in their cloud. Assuming one of the DLCIs represents the Internet, there are a number of ways to get routes established to it. OSPF was ACCs preferred method, but RIP or static routes could have been used as well. Ideally, from a routing perspective, every site in the customers cloud would use the Internet DLCI to be their default gateway, assuming it is fully meshed. If not, then a single customer DLCI might be pointed to the Internet DLCI, and all others would point back to that single customer DLCI. This would minimize the number of PVCs and provide better security at the IP layer. So to the point of hacking in from the Internet. If someone got access to the Telco's administrative network and was able to create a new DLCI within the customer's cloud, it wouldn't get them anything. Until each of the routers within the customers cloud had been configured to recognize the new DLCI, they'd have no PVCs to the new DLCI. It happened once to me, after my cloud was completely defined and running perfectly, the Telco supposedly had to reload their customer DLCI database. In the process of doing this, they screwed up the input and interposed two DLCI numbers at one of my sites. The result was that since the DLCI numbers no longer matched at each end of the PVCs I had created, the link was hard down. No amount of tinkering at my end was able to resolve the problem, despite the fact that the site in question was getting valid feedback from each of its known DLCIs (they were up, but they couldn't communicate). Obviously a single Internet DLCI in a customer cloud means that, assuming routing is dynamic, Internet packets could get to anywhere in the cloud, thereby forcing the use of Firewalls at all sites in the cloud. If routing has been set to prevent access from/to the Internet DLCI from/to all other DLCIs save one, then a single Firewall would protect IP traffic (if the attack was below IP, that's another issue). So I'd say that the cloud was safe from having a new DLCI hacked into place, which means the attacks would either have to be below-IP or IP-based. I know of no below-IP attacks. Besides, my routers all set off alarms whenever a DLCI was brought up or down, including the introduction of a new, unknown DLCI (as was the case when I introduced a new site into my cloud, which I then had to go and manually configure on all my routers). Cheers, Russ >