Encrypting private circuits (VPN over Frame Relay and MPLS)

Archive for May, 2004

Encrypting private circuits (VPN over Frame Relay and MPLS)

Posted by

This is a summary of a debate I recently had with a network engineer. The question is whether or not to run a VPN over a private circuit.

Let’s start with a quick definition of terms.

Private circuits are provided by the telcos to sites that companies own. So say you have a site in Detroit and Chicago. Way back when, the way to connect the two was to run a dedicated line. A dedicated line provides dedicated bandwidth and constant latency at a price. This was rather expensive. For redundancy, you purchased separate lines.

Frame Relay was the telcos solution. You can think of Frame Relay as a virtual dedicated line. The connection relays network frames (layer 2 or data link) over several physical networks to create a logical end-to-end line. The Detroit-Chicago traffic crosses any number of devices and circuits, but the link is presented to your layer 2 switches like a dedicated line. This cuts down the cost. The trade-off is varying bandwidth and latency because Frame Relay is a shared resource. Like dedicated lines, you needed to purchase separate circuits for redundancy.

MPLS (Multi-Protocol Label Switching) aims to provide performance of dedicated circuits at the cost of frame relay. MPLS adds traffic management and in-network redundancy. Detroit-Chicago over MPLS is still a shared resource, but now the link can more effectively shape the traffic and utilize the networks of circuits. Redundancy is baked into the circuit.

In terms of cost, it goes redundant dedicated lines, redundant Frame Relay, and MPLS. All three are rather expensive. Meantime, the Internet reliability has increased and cost has decreased. Strictly from a costing perspective, you might build the Detroit-Chicago link with a VPN (Virtual Private Network) over the Internet. Like MPLS and Frame Relay, VPN is a logical end-to-end line that builds on top of a physical network.

Now to dive into the confusion.

Telcos sell dedicated lines as private circuits. Telcos sell Frame Relay and MPLS as virtual private circuits. The argument you will hear is that security is built-in because these are private circuits. There is also the operations efficiency of not having to deal with routing infrastructure and possibly even IP infrastructure. (Novell administrators love Frame Relay as they can run IPX/SPX over it.) A private circuit is private, right? Not exactly.

First, all the telco equipment between Detroit and Chicago have visibility into the IP traffic. A truism of network security is that a network is only as secure as the people who have access to the equipment. In this case, that could be any number of telco support technicians. They can read your packets.

Second, the privacy of the private circuit depends upon the correct configuration of the equipment. Your packets and some other organization’s packets are streaming down over the same routers. The only difference is the tags in the packets and the how the routers treat those tagged packets. When improperly configured, the circuit fails open. I have seen situations where new IP subnets suddenly appear on the LAN switch, and are traced back to a misconfigured frame relay. Whose packets were they? Did the owner of those packets know he was broadcasting onto our network? Probably not.

My recommendation.

Treat dedicated lines, Frame Relay, and MPLS circuits the same as you would untrusted Internet circuits. Encrypt all internal traffic that travels over these circuits.

Virtual private circuits are not the same as Virtual Private Networks. One is clear text and the other is encrypted. The first ensures availability and integrity. The second ensures confidentiality. For best results, run a VPN over a virtual private circuit.

What about bandwidth and latency? With decent gear, the bump in thru put should be no more than 10%. Look for routers or firewalls that advertise encryption and line speed.

What about packet shaping? Use the QoS preclassify features of your gear. This reads the DSCP/TOS from the unencrypted packets, and writes it to the encrypted packets. The MPLS gear can then handle the encrypted packets properly.

What about complexity and cost? The trade-off is security for operational complexity. You may need to purchase more gear. You will need to implement IP routing. These add to the overall cost of the solution. Given the increases in security of encryption over clear text, the trade-off is worth it.

Sending Windows event logs to Syslog

Posted by

Many network devices utilize the Syslog protocol for sending logging to centralized log management tools. But Windows utilizes a proprietary logging format in Application, Security, and System logs. How can we get these logs into Syslog?

Check out the NTsyslog project on Sourceforge. NTsyslog installs as a Windows service. Periodically, NTsyslog polls the Windows event logs. The service then re-formats the the event and sends it out over the Syslog protocol. Under the hood, NTsyslog is written in Microsoft C++ and leverages the Microsoft Foundation Class Library (MFC) to access the Win32 API. NTsyslog is available for free under the GPL license.