Ron, It looks like you have a good base of discussion on the security aspects of Frame Relay. I think that for "private" frame relay links you could make the assumption that the probability of your FR being compromised is roughly similar to the probability of a dedicated line being compromised. Insider attacks are still difficult. Your DLCI number only has local significance between you and the upstream FR switch. The only way information could be re-routed would be inside the FR cloud. This would have to be done by someone who has access to the FR provider's equipment, or knows how to exploit the FR switches within the cloud (I am not aware of any common exploits, but this is most likely because they have not been discovered). However, if you are concerned about privacy or have any type of proprietary/confidential information crossing these links at all, I would strongly suggest (if the budget allows) using some type of encryption over these links. The strength of this encryption could be scaled to the sensistivity of the data. Remember, in the network security/integrity, world we must cover up every security hole possible, whereas the cracker only needs to find one way in. Gaining access to the Frame Link might enable a cracker access inside a (once private) network as well. Geoffrey Gates Computer Network Engineer Lockheed Martin > > Date: Thu, 2 Dec 1999 22:36:27 -0600 (CST) > From: Ron DuFresne <[EMAIL PROTECTED]> > Subject: summary on frame relay security questions: (fwd) > > Folks, > > Here's a summary of the replies to the questions I put forth to two of the > firewalls lists, concerning security and frame relay, with an emphasis on > private FR, and the replies generated over the course of the last few > weeks: > > There were between both lists, I believe 19 individual replies, the lists > might not have seen all the replys as I received a few in private. > > Sorting through those, I dropped 3 as content was not really topical nor > inciteful as pertained the topic. 4 others were more ponderings of the > potential threats and leaned more towards additional requests for > information concerning the topic. 2 more were then excluded as being more > in depth repeats of information already contributed. This left 10 meaty > replies. > > Most folks tended to respond that security of the FR cloud was pretty > solid, unless one either had access to the providers equipment or a > customers access point. I have heard nothing concerning freely available > tools to do this, and all the information I have on the matter points to a > high-end traffic analyzer being needed to get at at least the LMI level of > the traffic to be included in scarfs. But, the cost of a high-end traffic > analyzer is not all that unafordable these days, there were prices > mentioned of 1-3k <US>, I recall higher costs, but, those were back 8-9 > years past. Thus your main risks appear to be the telco/ISP <local > authorities?> itself and their security perimeter. Misconfiguration > appeared a few times as not only possible, but mentioned as factual > happenings of leaking information down the wrong pipe. Any clients > of the cloud and their security perimeter, with either 'not so nice'<TM> > business intentions or a rogue employee with access, pose the same threat > threshold. It was a few times emphasized that the the issues get to be > more interesting as endpoints traverse provider and national boundaries. > > There were replies that mentioned the possibilities of DOSing out others > in the cloud as being one of the easiest attack methodologies <same as IP > traffic in general>, though, there was mention also of social engineering > of actually been successful in gaining the re-routing of connection endpoints, > though an example was not provided. > > Interestingly, encryption of traffic was mentioned in only two of the > replies <20%>. One of those, from someone that had FR access as > provider/client/user was strong in claiming that FR traffic is rarely > encrypted, and when it is, it is most often only financially directed > information that gets any added manipulation to the payload. The other > being emphatic that any publically passed data requires encryption. This > leaves one strongly with the impression that perhaps folks' paranoia often > gets devoted most often towards directly connected Internet channels, and > back-ends might often be considered 'safer'. - [To unsubscribe, send mail to [EMAIL PROTECTED] with "unsubscribe firewalls" in the body of the message.]
