How secure is frame relay?

Some readers have requested that we describe the degree of security that is inherent in a frame relay service and whether or not it would be advisable to layer special tunneling protocols and encryption on top of their service. The bottom line is that you don't need tunneling, but you might want to encrypt your most sensitive data to protect it from intruders, as you might wish to do with private lines or any other type of network.

Let's consider permanent virtual circuit (PVC)-based frame relay networks first. Traffic is transported over a connection-oriented infrastructure that by its very nature creates built-in "tunnels." The addition of Layer 2 Tunneling Protocol (L2TP) or other tunneling protocols would not really add much to the privacy already inherent in PVCs, which represent a logical private network operating over a shared public network infrastructure.

Each end of the PVC has a unique data link connection identifier (DLCI) that defines which pairs of sites can communicate with each other within a given enterprise's logical private "subnetwork" of a public frame relay network. The network operator predefines these DLCIs, and this preconfiguration constitutes the "permanent" nature of the virtual circuit. Because end users cannot create connections at will, there is no possibility of sending or receiving information to or from unauthorized sites. This logical partitioning of network circuits keeps user traffic separate and secure within the shared network. Of course, within the network, the operations staff may have access to the information, but this is no different than with a leased-line network. Further, some degree of access to the information is needed in order to perform necessary diagnostics.

In addition, there are cyclic redundancy check safeguards built into frame relay to compensate if a DLCI should become corrupted. If any errors are discovered in the frame as part of the data or the address, the frame is discarded before it is passed to a higher-level protocol and reaches an unintended destination. If a frame were to somehow still get misdelivered, it is unlikely that it would be in a meaningful form within the frame relay frame. Rather, it will be a segment of information from a higher layer protocol, such as TCP or SNA. That higher layer protocol will see the misdelivered information as a protocol error and will discard it long before it reaches the presentation layer, where it can be viewed.

Coming: SVCs and encryption issues and options

---

Steven Taylor, consultant and broadband packet evangelist, and Joanie Wexler, an independent networking technology editor and writer, team up to bring you this analysis and commentary. Taylor specializes in education and market analysis, and Wexler adds incisive reporting and research. For more detailed information on most of the topics discussed in this newsletter, connect to www.webtorials.com, the first Web site dedicated exclusively to market studies and technology tutorials in the Broadband Packet areas of Frame Relay, ATM, and IP. Feedback and additional topic ideas are welcome. Please contact taylor@webtorials.com or joanie_wexler@mindspring.com>

Frame relay rolls on...
Network World, 04/26/99

Frame relay security: What about SVCs?
Network World, 12/16/98

Frame relay security: DLCI corruption is no big deal
Network World, 12/14/98

Frame relay security: Why PVCs preclude the need for tunneling
Network World, 12/07/98

Archive of Network World on Frame Relay newsletters